Re: The future (dependencies on libc{5,6,6.1} &c)
Nikhil Nair <nn201@cus.cam.ac.uk> writes:
> 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.
The package compilation process takes care of this. If a package
doesn't insert dependency information dynamically (and some haven't,
which is why my older libg++ contains a libc5 dependency, though I
think that's been fixed), the package is broken.
When you build the package, you run dpkg-shlibdeps over one or more
executables. This runs ldd on the package, parses the output to see
what libs the thing is linked with, and then looks through
/var/lib/dpkg/info/*.shlibs files looking for matches on each of those
items.
Thus the only package that has to worry is the libc6 package itself,
which has to be sure to put the right .shlibs file in so that on the
alpha, the file reflects the 6.1 soname, or 6 on everything else.
It really does work, honest. I have a couple of issues with the
system, but this is not one of them. It's quite cleverly engineered.
> 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?
Better to fix the real breakage---any packages that don't have
dynamically generated dependencies---than modify the libc packages to
report erroneous information. Ditto for the other libc5 stuff.
I know it's a pain, but I have to marvel at where people are finding
these packages with the broken deps---I haven't had any on my system
for many moons. This is, of course, why I'm in many ways quite
useless at helping people with some of the bumps on this particular
road.
Really, the packaging system is designed to take care of this, it's
just a matter of taking care of a few packages which weren't done to
spec. Most packages require 0 mods to compile, and most of those are
very system dependent, or aren't yet set to deal with glibc---a
situation which is changing rapidly as i386 stuff changes over.
> 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.
That might be feasible, but mostly we should just get diffs in the bug
system. That's worked fine for me.
Once I am at my new job (and after my PII arrives), I intend to take
the UDB into work and turn it into an "open" compilation platform (via
fakeroot), so hopefully developers can recompile stuff themselves.
Mike.
--
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: