| 1 |
On 2007/12/20, Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
| 2 |
|
| 3 |
> Uh, it works in both those cases. The package manager will simply not |
| 4 |
> see the ebuild at all. |
| 5 |
> |
| 6 |
> Which is pretty much the point... |
| 7 |
|
| 8 |
Yes, because a change in the way EAPI is read implies a change in the |
| 9 |
files naming rule, so that the PM recognize the file only if it can |
| 10 |
do something useful with it. That's true for both proposals, which |
| 11 |
was pretty much my point. And that thus, it was not an argument in |
| 12 |
favor of one against the other. |
| 13 |
|
| 14 |
I still think that changing file names when absolutly required |
| 15 |
(switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or |
| 16 |
switching to xml, etc.) is less disturbing than changing it for every |
| 17 |
single new EAPI. It's not because one new extension may not be |
| 18 |
eternally enough that we should introduce an infinity right now. |
| 19 |
|
| 20 |
But yeah, to be honest, you're right that my original "as long as |
| 21 |
ebuilds stay bash" was a bit optimistic: it was assuming there would |
| 22 |
be no decision of changing that rule as long as there would be no good |
| 23 |
reason for it (like a switch to xml or whatever other not-bash format). |
| 24 |
|
| 25 |
-- |
| 26 |
TGL. |
| 27 |
-- |
| 28 |
gentoo-dev@g.o mailing list |
Archives