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