Re: Dependancies on libc
On Wed, Jan 23, 2002 at 09:00:14PM -0700, Joel Baker wrote:
> Having run into a few packages, now, which have dependancies on specific
> GNU libc versions (or rather, libc versions, when all that the packaging
> system understands is libc == GNU libc), which compiled just fine under
> the NetBSD libc, I come to the following conclusion:
>
> We should request that a provision be made for desginating which libc is
> required, from the developer/policy community. As a starting point, I'll
> toss out one possible resolution:
>
> Rename the libc-* packages to libc-gnu-* (or gnu-libc-*), and use Provides
> headers to "fake" the old names, for a period of time (IE, to allow a grace
> period in which packages which depend on libc can change their dependancy
> listing). Other libc packages would then be libc-netbsd-* or netbsd-libc-*
> in a similar fashion, allowing proper dependancy declarations for any libc
> packages which might end up being part of Debian.
I'd strongly recommend not doing this. Firstly, Provides: don't work in
the case of versioned dependencies, and I suspect not for versioned
build-dependencies either, so you're asking every other architecture to
switch over several thousand packages all at once just to adjust the
naming. That's not a good idea.
Secondly, each architecture really has to have only one libc; when you
switch to another one, you're effectively creating a new architecture
anyway, and it doesn't matter if package names clash between
architectures. Furthermore, the glibc packages already have different
names on three Debian architectures (alpha and ia64 use libc6.1{,-dev},
while hurd-i386 uses libc0.2{,-dev}). Since one of those architectures
was released with potato and another will release with woody, people
should have got used to dealing with this a long time ago.
I assume you're talking about 'Build-Depends: libc6-dev (>= foo)', so
you can use the fact that build-dependencies can include architecture
restrictions. They'll end up looking something like this (depending on
exactly what the netbsd-i386 libc is being called):
Build-Depends: libc6-dev (>= foo) [!alpha !ia64 !hurd-i386 !netbsd-i386], libc6.1-dev (>= foo) [alpha ia64], libc0.2-dev (>= foo) [hurd-i386], libc-dev [netbsd-i386]
Yes, it's ugly, but not many packages should need versioned
build-dependencies on libc6-dev. If anyone has an unversioned
build-dependency on libc6-dev, you can file bugs against them, as
libc6-dev is build-essential on the architectures which have it.
As for binary dependencies on libc6, well, those are usually generated
using shlibdeps anyway.
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: