On Tue, Feb 15, 2005 at 02:38:34PM -0700, Joel Aelwyn wrote: > 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: > > > 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.
So to summary: several plateform does not have a libc6-dev package, but have a libc*-dev that Provides libc6-dev. You would prefer if it was only necessary to Provides libc-dev instead, which make a lot of sense. However, I don't see what 'libc6-dev | libc-dev' achieve over 'libc-dev': on ia64 and alpha (which are autobuild), 'libc6-dev' is a purely virtual dependency, and so is 'libc6-dev | libc-dev' and 'libc-dev'. So why not change the dependency to libc-dev ? > 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. Except there is no libc12-dev on packages.debian.org. > 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. Please note it is not here listed as a build dependency, but as as dependency of libjpeg6b-dev. libc6-dev is build-essential so is never installed due to Build-Depends, but through the build-essential package. This dependency is for the benefit of people that want to build software linked to libjpeg. > 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'. I well know that, but 'libc6-dev | libc-dev' does not achieve that on alpha and ia64. If we really want to achieve that, the simplest way is to have Depends: field that depends on the architecture and list the real > 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". That is a different problem: on what libc*-dev a -dev package should depends ? Obviously one that allows to build programs using the library, so probably the same as used for building the library. Also using the number 6 to mean 'GNU libc' and the number 12 'BSD libc' is not specially descriptive. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
