On Tue, Feb 15, 2005 at 11:51:45AM +0100, Bill Allombert wrote: > On Thu, Feb 10, 2005 at 11:29:43PM -0700, Joel Aelwyn wrote: > > Package: libjpeg6b > > Version: 6b-9 > > Severity: minor > > > > The libjpeg62-dev package currently Depends on 'libc6-dev'. In most cases > > (including, as far as I can tell, this one), this is an excessively strict > > Dependancy; the value 'libc6-dev | libc-dev' should suffice (note that you > > can't simply do 'libc-dev', due to limitations of the packaging system, > > currently). > > Hello Joel, > > libc6-dev is the only package that provide libc-dev, so it is not > strict, let alone excessively strict. I suspect you are referring to > non-glibc ports. In that case, 'libc6-dev | libc-dev' is not correct > because on a non glibc port, libc6-dev will not exist and libc-dev > might be a purely virtual dependency. > > I propose you restate the problem you really have, and we try to address > it correctly.
libc12-dev properly Provides: libc-dev. Please look at the virtual package
list declaration for what libc-dev implies; that 'standard C library
headers' are present.
Among other things, even on glibc-based systems, it isn't only libc6-dev;
it's also libc6.1-dev, libc0.2-dev, and libc1-dev. Most of those ports have
ugly hacks such as Provides: libc6-dev to work around packages that don't
properly declare what their build dependancies are, which is why bugs like
this one have gone so long.
The only reason the correct answer isn't just 'libc-dev' is due to package
tools not being able to cope with not having at least one real alternative;
it is a broken situation in APT/dpkg, with the workaround of 'always
specify at least one real package that satifies the dependancy'. Otherwise,
most of the packages which currently have libc6-dev really could make
do with solely libc-dev; unless your package is actively using GNU-only
extensions (which appears highly doubtful, since, well, I can compile
things using it just fine, having installed a local version with the
adjusted dependancy on a libc12 box), it isn't a correct dependancy.
As far as libc-dev effectively being a pure virtual dependancy - yes,
it boils down to that, but it is a pure virtual dependancy that, on any
given platform, normally has exactly one package that can meet it, thus
avoiding the situation that actually causes APT/dpkg to break (being
unable to decide between multiple available packages which all satisfy the
dependancy).
Adding a Provides: libc6-dev to libc12-dev (as the other ports do if they
have a different glibc version) would, for obvious reasons, not be a
correct solution either, because then there is no way at all to say "No, I
mean it, this really needs GNU libc development files".
I will note that checking the archives of debian-devel will show some
extensive discussion (not all of it going the way I would have preferred)
about what the workable solution to this situation is, but the final
conclusion was that things which aren't GNU libc specific should use the
'libc6-dev | libc-dev' form, because it shortcuts on the most common build
platforms, and works on all of the rest.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
