| 1 |
Hi, |
| 2 |
|
| 3 |
Duncan <1i5t5.duncan@×××.net>: |
| 4 |
> > Potentially the developer could just manually put the EAPI in the |
| 5 |
> > manifest (or use a tool to do this). Obviously this is an extra |
| 6 |
> > step when adding ebuilds to the tree, but that would completely |
| 7 |
> > address the issues with sourcing builds. |
| 8 |
> |
| 9 |
> That's an interesting idea. A "manual" method for putting the EAPI |
| 10 |
> in the manifest, thus bypassing the chicken/egg issue of needing to |
| 11 |
> need the EAPI to source the ebuild... to get the EAPI. |
| 12 |
|
| 13 |
Having the EAPI stored outside the ebuild's scope is generally a bad |
| 14 |
idea, because someone has to tell you that the ebuild you just |
| 15 |
downloaded from Bugzilla is EAPI x. And the package manager will be |
| 16 |
totally confused when assuming an EAPI that is wrong. So the EAPI |
| 17 |
should be stored inside (best solution regarding giving ebuilds away) |
| 18 |
or in the file name (best compromise regarding the whole situation. |
| 19 |
|
| 20 |
V-Li |
| 21 |
|
| 22 |
-- |
| 23 |
Christian Faulhammer, Gentoo Lisp project |
| 24 |
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode |
| 25 |
|
| 26 |
<URL:http://www.faulhammer.org/> |
Archives