Re: dependancies on libc5
On Fri, 10 May 1996, Brian C. White wrote:
> Since so many packages depend upon libc5, would it not be a good idea
> just to label it as essential? I'm sure there are many packages that
> currently should list libc5 as a dependancy, but don't.
I, for one, think that having packages depend explicitly on all the shared
libraries they use (with major version number in the lib package name) is
a great idea...
1. It lets you see which package needs a given shared lib.
2. It prevents you from shooting yourself in the foot by removing a shared
lib that you though nobody needed anymore.
3. If some package needs a new major version of libfoo.so.x, you'll be
told so and then you just install libfoox alongsides the older libfooy.
4. It makes clean upgrades to a system that uses the next version of
Contrast this to the Windows DLL mess, where you can never quite know
if it's safe to remove a given DLL and which programs use it.
I think the way Debian is handling shared libs is the right way. And if
some packages forgot to depend on libc5 when they needed to, then we
should fix the control file for these packages, not make 'Depends: libc5"
>From what I understood, having packages depend explicitly on libc5
is what makes a clean upgrade to ELF possible... And if all a.out packages
would have used 'Depends: libc4", then it would have been possible to do a
clean partial upgrade to ELF, which would have been even nicer. And
simillarly if we keep the explicit 'depends: libc5' then our users will
hardly notice it if Linux ever moves to libc.so.6...
Btw, it'd be rather easy to have some kind of automated check for shared
lib dependencies in dchanges/whatever else. All you need to have is a
table mapping the .so name to the package that provides it. Then you just
run ldd on all the executables in the package, build a 'Depends' using the
.so mapping table and compare that to the 'Depends:' line in the .deb
PS Just to make sure, mandelspawn wasn't missing a 'libc5' in its
'Depends'... It was a.out.