alan buckley wrote:
I've tracked down the bug to the control
record of the sharedlibs package which has
a dependency to sharedunixlibrary. The problem
is the case is incorrect the package name
should be SharedUnixLibrary - case is important.
Thanks.
If you look at the SharedUnixLibrary control
record it is the "Package:" entry that controls
the name of the package not the filename.
I can guess that the package names were all
changed to lower case at the last minute to
match the others on the autobuilder website,
however this doesn't match the mixed case for
the main package riscpkg site. Although we
could go for lower case for things like gcc
if we really wanted to, I don't believe we
should for packages that will be shared with
other sites e.g. SharedUnixLibrary.
I have been grappling with this issue, and
on balance, decided that lower case was going to
be better.
The SharedUnixLibrary package has already
been defined with this name for NetSurf so
I do not think we should change the case
now.
I was hoping for a Provides: field to address
this issue. Which we really need in any case.
I guess it's a matter of taste, but I prefer
the mixed case package names. The autobuilder
ones are lower case because they were directly
generated from the names on debian.
Mostly true, this is a bit more explicit now
with some of the recent changes. However, having
the package name be the lower case Debian package
name has some consistency, and perhaps some other
advantages. As it is, there are several names
associated with a package: The RiscPkg package
name, the zip filename and one or more RISC OS
application names. Sometimes these are all
different, and getting it all right has proven
to be a bit tricky.
I agree that the upper case names do look a
bit better, and in many cases would exactly
match the application name, as well as being
something more suitable to generate a wiki
page from (which might have a 4th different
name).
Also for some reason the location GCC has changed
to Develop from Development. Development was
chosen originally because that is the section
name specified in the riscpkg Policy Manual.
Yes; packages in riscos.info have been "Develop"
for a long time, due to my overlooking of this -
I noticed it recently, but I felt it was too
late to change before release. Some of the
riscpkg.org packages are actually under "Programming".
Incidentally, many of the packages presently under "Library"
should instead go under "Development" since they're
actually -dev packages. But I'll address this wholesale
when I have the boilerplate for packaging dev/shared libs
in one go in the autobuilder.
Other considerations here include that riscpkg.org
packages aren't going to be updated any time soon,
from my discussions with Graham, and that where it
makes sense, we should provide replacements for
them (which is where the Provides: field helps).
The argument could be made that without Graham's
active valuable input, we have a degree of freedom
here.
I'm well aware that we're on the verge of creating
an "RPM hell" if we aren't careful, and that
ROOL may soon be providing its own packages, although
I would hope its offerings are 100% non-overlapping
with riscos.info packages.
I'm not adverse to again making large changes in the
riscos.info packages, but it's certainly to the point
where we need to discuss them.
_______________________________________________
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
