The future (dependencies on libc{5,6,6.1} &c)
Hi again,
A few thoughts.
My impression so far is that Debian/Alpha, once installed, is not bad at
all. I don't know how it compares to RedHat, but I think it should be
able to compete fairly soon.
However, installation a nightmare for anyone who doesn't know Debian
inside-out. It's not even nearly dselect'able, not just because packages
are scattered everywhere (and lack of Packages files), but because lots of
dependencies are broken.
I think it should be an *urgent* priority to get a dselect'able tree, with
all uptodate packages, in one place. Then, with just a few more fixes, we
should be able to start coaxing some RedHat types to come have a look and
feed back comments. Not until then will we really get the momentum
towards a release.
One major factor is that we're not using Master. I suspect we're the only
port which isn't. Is this mainly because some of our people aren't yet
official Debian developers, or because the source system there won't allow
for package-specific patches? Either way, this *must* be sorted out.
As a stopgap (and only in the short-term, mind), I'm willing to set up a
dselect'able tree, mirroring all the other sites with .deb packages
(master mirror + beezer, gorba &c) and automatically collating the .deb
files into a master-style tree (generating a Packages file etc.). I'll
need help with some of this, maybe Guy will help me out with the Packages
file generation (master does this sort of thing, of course).
Thoughts?
On to dependencies etc.
Presumably, we intend that most packages won't need any Alpha-specific
patching. As I see it, this is impossible if our libc6 is called libc6.1
... all packages which depend on libc6 must be changed to depend on
libc6.1 - that's a lot of packages.
There is a simple fix, though. I propose that libc6.1 should provide
libc6, and libc6.1-dev should provide libc6-dev. Such a change would hide
this Debian/Alpha quirk, and should remove lots of dependency problems.
As loong as we're sure we've irradicated all old .deb files which depended
on the old glibc, we should be OK. Mike?
I'd be interested to know when the i386 port expects to irradicate
libc5-based packages. If there will be packages around for a while which
`depend' on libc5, but can be compiled on the alpha, maybe libc6.1 should
provide libc5 as well ...
[Of course, by `provide', I mean lists the provided packages on the
Provides: field without any extra files in the providing package.]
One thing: we're going to run into trouble with revision numbers. From
what I've seen, we've been using single number revisions, although a lot
of this stuff is non-maintainer releases, and where the source is ...
well, I may know, but the original maintainer, to whom bugs will be sent,
will probably not know.
I suggest that, for any packages needing alpha-specific patches which are
not yet in the main Debian source should have different revision numbers,
e.g. packages foo_1.2-3 should become foo_1.2-3a1, foo_1.2-3a2 etc. (`a'
for alpha, of course). This would make it easier to keep track of which
packages needed special patches.
OK, I've said quite enough for now ... I'd be interested to hear your
thoughts.
Cheers,
Nikhil.
--
Nikhil Nair
Trinity College, Cambridge, England
Tel.: +44 1223 368353
Email: nn201@cus.cam.ac.uk
nnair@debian.org
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: