| 1 |
Richard Freeman <rich0@g.o> posted 49B57409.5050406@g.o, |
| 2 |
excerpted below, on Mon, 09 Mar 2009 15:54:49 -0400: |
| 3 |
|
| 4 |
> If the developer of an ebuild prepares the manifest, then at least their |
| 5 |
> package manager will know how to handle the ebuild and extract the EAPI. |
| 6 |
|
| 7 |
Good point. The dev's PM will presumably be updated to whatever EAPI |
| 8 |
he's committing, even if they user's isn't. That does help some. |
| 9 |
|
| 10 |
> However, end-user package managers wouldn't need to source the ebuild |
| 11 |
> to figure out the EAPI. |
| 12 |
|
| 13 |
If I've been paying attention, that isn't necessarily the case. Ciaran |
| 14 |
can better answer why than I can, however. |
| 15 |
|
| 16 |
> Potentially the developer could just manually put the EAPI in the |
| 17 |
> manifest (or use a tool to do this). Obviously this is an extra step |
| 18 |
> when adding ebuilds to the tree, but that would completely address the |
| 19 |
> issues with sourcing builds. |
| 20 |
|
| 21 |
That's an interesting idea. A "manual" method for putting the EAPI in |
| 22 |
the manifest, thus bypassing the chicken/egg issue of needing to need the |
| 23 |
EAPI to source the ebuild... to get the EAPI. |
| 24 |
|
| 25 |
> Changing the manifest format of course creates backwards compatibility |
| 26 |
> issues. |
| 27 |
|
| 28 |
That's likely the biggest issue, potentially making this a "wait a year" |
| 29 |
solution. But if we got in the PMs and started the clock now... |
| 30 |
|
| 31 |
> So, I wouldn't dismiss this idea out of hand - it isn't completely |
| 32 |
> equivalent to the other options. |
| 33 |
|
| 34 |
True. It may well be one component of a full solution, even if it |
| 35 |
doesn't on its own provide a full solution. |
| 36 |
|
| 37 |
-- |
| 38 |
Duncan - List replies preferred. No HTML msgs. |
| 39 |
"Every nonfree program has a lord, a master -- |
| 40 |
and if you use the program, he is your master." Richard Stallman |
Archives