-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ciaran McCreesh wrote:
> On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
> <[EMAIL PROTECTED]> wrote:
> | Ciaran McCreesh wrote:
> | | Well... What I was mainly thinking (and assuming we don't have the
> | | new virtuals system by whenever this becomes relevant) is that a
> | | metapackage could represent, say, "the core x11 libraries as
> | | provided by xorg". This is all well and good, but there are other X
> | | implementations out there. It could well save a lot of work in the
> | | long term if deps were generally upon "the core x11 libraries"
> | | instead.
> |
> | But see, that's the thing; no packages should just generally say "Give
> | me the X libraries" other than temporarily. They should be
> | specifically demanding upon the exact libraries they require.
>
> Hrmmmmm. Is this going to be sanely doable by your average dev? How long
> a dep string would we be having in typical cases? How about in bad
> cases?
>
The more formal the depstring, the quicker the packages build ( using
only needed packages instead of lumping them in one group ). This is
essentially what the DEPEND should be, just what the packages needs to
compile and run. This especially benefits embedded targets who need a
bare-bones set of libraries and nothing else.
> | | Is it your assumption that in the future xorg-x11 will be the only
> | | serious X server?
> |
> | My assumption is that if there's another fork, it will be easier to
> | deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every
> | single package X provides.
>
> So X deps will be by package ('either xorg-libfoo or forkx-foo or
> sgi-x'), rather than by concept in the future?
>
I think concepts are important and abstract complexity from a packages
DEPEND. However, having the DEPEND be accurate is important as well.
This almost reeks of the USE group GLEP being applied here as well.
Setting up DEPEND-set would be great for this, although it is difficult
to imagine sets that can be shared between many packages. eclasses are
marginally decent for this right now anyway.
> | | *shrug* I realise we make similar assumptions about a lot of
> | | packages, but X is a) an at least vaguely standard protocol, b)
> | | heavily depended upon and c) implemented by more than one vendor.
> |
> | Indeed. But what I've begun to discover is that virtuals aren't always
> | the best solution when there is more than one provider, much less when
> | that's a largely hypothetical question.
The problem with the individual approach is if I wanted to run XFree,
or a competing X implementation, I have to add about 200+ packages to
/etc/portage/package.provided. This is not clean at all; it's hideous.
If I add the meta-build to /etc/portage/package.provided it just means
that I am managing the meta-ebuild and it is valid to count it as
installed for dep calculation. This is not true of any of the
dependencies of the meta-ebuild however. Thats just what I remember fro
m discussion about it, so correct me if it's wrong ;)
>
> Mmm, possibly true. For the big things though, I was hoping we could
> switch more towards depending by concept rather than by implementation,
> especially once we get improved virtuals. The current X situation is
> sort of a concept dependency -- moving away from that could arguably be
> seen as a regression from one perspective.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQu6u+GzglR5RwbyYAQI+Jw/+NZ1e0S687AjvBFwbK9qOGekgjd37WIxk
w5Y+t66OgULeU9XTNRW9hLY63Eg7q5nOByAH4HyUwntrgPTHr9s3c/GhP80f4Jwa
cDfhSnR6axMaNS5CgmZ/DyrfVGlCPTa6JWWdjt9rTcuFIIx1/SbMxcGcg0Lv7JJE
SCGchwugKOjoy+uhsEDVh6/nUhzdb/Nj5wsz/CbNdFPtnob87w/iTB0AVcNyXn2T
fJ4q5Lvrmb1/CyUso26am2dpAw+0xY0kmWSDzBxiMPbP06zX39ZrMEkTxLfsQoZO
ISVQmQ5K532qWpziSaktDtzKdxcw+vJU9ObelJX2deGyurl7mUxfjALoQ702eSI7
1Bmx9QqvtGWWmzDRtw1VNXr0645QKX+HFsPR1o9vZHqT2orKLs6FcHTjNKr6nCRx
Y0ixYRSSwk5Ik3WeG/3ydNJs45NrcOa9qE66uU9OIvM+ONIxVTey6WpF/XGHqcC/
6K8QiQw1eJV5qIK3vH72dZ+B+Bk9fYX3Pn+q7gVLYHFekCIVwxZu0R6wWkQIcgAt
fb6WLILnduo4wvDdgRToTswdaQbxP5qaX7Y4uB1PerXDgwG4/kVK+ZhYVjhJpnN2
nj38OBLQZUJ0WaiReYygiFz1ePiaAWG4Fy2uH/kNUFsHt0QvjFnzkw+7s9/dst6t
j42vluI+/fk=
=O+1e
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
