| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Ciaran McCreesh wrote: |
| 5 |
> On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner <warnera6@×××××××.edu> |
| 6 |
> wrote: |
| 7 |
> | > Hrmmmmm. Is this going to be sanely doable by your average dev? How |
| 8 |
> | > long a dep string would we be having in typical cases? How about in |
| 9 |
> | > bad cases? |
| 10 |
> | > |
| 11 |
> | The more formal the depstring, the quicker the packages build ( |
| 12 |
> | using |
| 13 |
> | only needed packages instead of lumping them in one group ). This is |
| 14 |
> | essentially what the DEPEND should be, just what the packages needs to |
| 15 |
> | compile and run. This especially benefits embedded targets who need a |
| 16 |
> | bare-bones set of libraries and nothing else. |
| 17 |
> |
| 18 |
> The problem is... By hard-coding a bunch of xorg packages, you're making |
| 19 |
> your DEPEND *less* accurate. Most packages will build just fine with |
| 20 |
> other X implementations. |
| 21 |
[1] Yes but at present we have only 1 provider of X11 in the tree |
| 22 |
(xorg). If we were to make a bunch of virtuals (concepts if you will), |
| 23 |
then all packages should/will work fine with xorg, because they are all |
| 24 |
tested with xorg. Then all of a sudden a new X server comes out, call |
| 25 |
it Foo. So we add Foo to our virtual/concept and things break...because |
| 26 |
no one has tested every package with Foo, it's only been tested with xorg. |
| 27 |
|
| 28 |
> |
| 29 |
> Providing a specific metapackage is a bad idea. What if a package really |
| 30 |
> does depend upon xorg? Providing a specific concept would be better. |
| 31 |
> Whether such a thing is implementable currently is up for debate... |
| 32 |
> |
| 33 |
[2] Virtuals are basically concepts, things are only added to |
| 34 |
virtual/mta fex, when they fulfill the concept and real-world |
| 35 |
requirements of mta. As long as one can define exactly what the |
| 36 |
real-world requirements of each x11 concept is, then it shouldn't be a |
| 37 |
problem. Mostly this is a discussion with x11 geeks about the standard. |
| 38 |
|
| 39 |
To sum up the two pieces of the above. In order to prevent [1] we need |
| 40 |
to come up with an agreement on what constitutes each concept/virtual |
| 41 |
[2]. Virtual/x11 was originally for xfree/xorg migration, but I don't |
| 42 |
believe that there is any kind of agreed upon requirement set for a |
| 43 |
package to be added to virtual/x11. A quick grep of the tree shows 2115 |
| 44 |
ebuilds DEPEND on x11, which is a lot of ebuilds to do QA on for any new |
| 45 |
x11 provider. Most other virtuals adhere to a simple binary interface |
| 46 |
( call sendmail, mail is sent), as opposed to X11's library based |
| 47 |
interface (although it has binaries as well.) |
| 48 |
|
| 49 |
-----BEGIN PGP SIGNATURE----- |
| 50 |
Version: GnuPG v1.4.1 (GNU/Linux) |
| 51 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 52 |
|
| 53 |
iQIVAwUBQu7I5mzglR5RwbyYAQLJdg/+OQf8MY16CMkmR4mceDPH+uTO+4dMwiqt |
| 54 |
MUVuXm520bH5jD0dITogxrPWNMZXLPY2topENKoCsvM0ex1hqB3/mNs9WcXre27a |
| 55 |
4QtowNX4rFG2oBSxFUEphvJD+dH9XUptBUaecL+g286G9rqlc6DNvl7LfHTokCa6 |
| 56 |
TmG2sbArEofOQpQOa4YPDfahUp9Bzvmusb9gLKHtMPIGokbmD4fSLhNVlAsqjH9L |
| 57 |
mrs6a+ZNt1GzOVAuDnnDUYYgIhHk5J4EEPTnqfZ4ByaKokUCSSMzzJ+fJDTkNBe9 |
| 58 |
Zz++vAcR2QaER0jvL3r99r4xMM/MYzrQMG+tbZ3i8UY/RQZ5u886s4K899bcAA0s |
| 59 |
qa0W9xP61vtxghQy60tkmdvFi3y+GVRGrNwVlPi82Mi8nrCBN19sj9N6k2xVetnr |
| 60 |
esJmZ7mL+JA0gmXAfGTZ8DUpi8huPwYtKcDBRTq7F9fpPGchiy/IXTnizcv5bQF8 |
| 61 |
C0ADKSdNshKasr/iGWfP+pGgCMWDsEOqe9hR8phRoECx6N0xCRPgfP/chvKIumvs |
| 62 |
oqVW2EEB0Wk6f3vUmp/vE5qIFX1T3UQGNkHtdRnwn48Btj/C0FfuEdmGqyCbR+Yp |
| 63 |
u/jW4AZGL8MrbkpbUIzJyR7gAYe3MAYt3QcBFgRuEX2W2bhD+K7R2jy3rfzEkLx4 |
| 64 |
dcXCpCyuqSM= |
| 65 |
=7TLN |
| 66 |
-----END PGP SIGNATURE----- |
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives