[gccsdk] GCC 4.1.1 Release 2 packages

[Peter Naulls]

Alan Buckley wrote:

> The shared unix library itself is provided in the UnixLib package
> from riscpkg which was installed in !UnixLib. A separate package
> put the development headers etc in the same place. So if you
> conflict with the UnixLib package it will cause a problem for
> all riscpkg packages (and the autobuilder ones) that use the
> shared unix library as uninstalling UnixLib should cause them
> all to be uninstalled.

I'm not sure of your reasoning here.  Ignoring the NetSurf
repo for the moment, riscpkg.org of course needs to provide
a consistent and complete set of packages.  As does
riscos.info, independently.  However, given that riscos.info
contains newer versions of packages (most notably GCC,
but certainly others in future), there's no reason for
riscos.info packages not to replace/conflict with them.
This assumes a resolution of the sul vs SUL naming, which
we don't yet have.

Remember that the use of !UnixLib at all is particularly
dated.

> Are we going to call the package "sharedunixlibrary" now?
> 
> If so we need to modify the add-riscpkg script to put this
> in the depends when the -unixlib option is used instead of
> UnixLib.

Understood.  I'm still sitting on this one.  Having again
reviewed the setup on riscpkg.org and NetSurf, I'm
prepared to be convinced that upper/camelcase is going to
be better for RISC OS.  I still have a nasty feeling
that there's some hidden problem here

If so, then this requires renaming of virtually all packages,
although it might be automatic for some types of libraries.
And given the complexity and surprising number of names involved
in one particular package, this is something I want to consider
further.  As I mentioned earlier, an uppercase name would
be (in 95% of cases) also the name of a matching wiki
page for that app.

>>
>> It allows virtual packages:

>>
> Thanks, this link makes it clear. This would seem to be a simple way
> to solve the problem if it had been implemented.

Do you think that this is something you can do?  If nothing else,
libpkg's propagation of errors needs much work, so we do not get
generic errors present to the app (such as when I had a $ in the
filename, confusing the unzipping).