Peter Naulls wrote on January 02, 2010
alan buckley wrote:
< On Fri, 1 Jan 2010 Peter Naulls wrote:
Incidentally, I also added to my
script some additional Conflicts: tags to really
ensure people don't try to use very old GCC 2.x
and 3.x (and the explicit !UnixLib).
Please don't add a conflicts with the explicit !UnixLib.
The sharedunixlibrary doesn't actually conflict with
!UniXLib, it will replace it in time though, but old
packages can still use !UnixLib.
No, but !GCC does, at least logically, which is where
the provides field comes in. I'm not entirely
sure of what you are objecting to here. !UnixLib is
only required (IIRC) with GCC 2.95, or if you really
want to use with Norcroft, but I think modern UnixLib
won't work with it - John abandoned that effort some
time ago. The point is to avoid potential confusion
about needing it.
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.
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.
The problem is introduced when adding the NetSurf
repository, since as you mention, that depends upon,
and also has, an upper case version. That will
have conflicting files with the lower case version
when you try to install.
There are a couple of things that can be done here:
- Rename the riscos.info package names to lower case.
I think I would have prefered at least the
SharedUnixLibrary package to retain the mix case as
it would fit better on the riscpkg site as I would like
to put a copy of it there so all future packages use it
instead of !UnixLib.
But !UnixLib never contained the module, did it? It
was always distributed separately for !System.
See above, !UnixLib did contain the module and the gcc
generated code used to check there first for it. I changed
this for GCC4 so that it now checks in !System first and
eventually the plan is to remove the check in !UnixLib
entirely.
- Implement the Provides: field.
I'm not sure what the "Provides" tag adds, can you
explain it to me?
It allows virtual packages:
http://www.debian.org/doc/debian-policy/ch-relationships.html
This is important for package renaming, should
that become possible, or if another package is
a superset of something else.
Thanks, this link makes it clear. This would seem to be a simple way
to solve the problem if it had been implemented.
Regards,
Alan
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK