On Mon, Oct 14, 2002 at 07:39:09PM -0500, Steve Langasek wrote:
> On Mon, Oct 14, 2002 at 05:50:26PM -0600, Joel Baker wrote:
>
> > > If you want to specify which of a set of real packages should be the
> > > default to satisfy a particular dependency on a virtual package, you
> > > should list the real package as an alternative before the virtual
> > > one.
>
> > However, as read, this would make little or not sense as to why one
> > cannot (or even should not) use libc-dev instead of libc*-dev unless
> > you need a versioned dependancy - since all libc*-dev should Provide:
> > libc-dev, and there should be exactly one that applies to any given
> > arch, there is no "preference" that would make any sense for all
> > arches.
>
> As a technicality, depending on libc-dev is wrong because there is always
> *one* *specific* real package that fulfills the proper relationship on
> each architecture. You cannot substitute a different -dev package for
> libc6.1 on an alpha and get correct results.
Er. If that's true, then why have a libc-dev virtual package at all?
Granted, depending on:
libc6-dev | libc6.1-dev | libc0.2-dev | libc12-dev | libc4-dev
would certainly work (for all variants of libc I'm aware of right now,
anyway) - but would be a bit fugly.
If folks really aren't supposed to use libc-dev to mean 'the proper libc
for the current arch', maybe a substvar would resolve this?
Depends: ${libc-dev:Depends} ...
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpnLIQzjMxBm.pgp
Description: PGP signature