| 1 |
Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
> On Mon, 09 Jun 2008 10:27:56 +0200 |
| 4 |
> Tiziano Müller <dev-zero@g.o> wrote: |
| 5 |
>> Ciaran McCreesh wrote: |
| 6 |
>> > No point. A 0 package manager still couldn't use a 0.1 ebuild. |
| 7 |
>> > |
| 8 |
>> That's true, it has at least to be aware the there's an EAPI. |
| 9 |
>> But how does such a package manager handle .ebuild-0 files? Ignore |
| 10 |
>> them? Failing because of unknown files in a package-dir? |
| 11 |
>> Should we care about package managers not being aware of the |
| 12 |
>> existence of EAPI's? |
| 13 |
> |
| 14 |
> Package managers can't do *anything* with ebuilds with unsupported |
| 15 |
> EAPIs anyway. Encouraging package managers to handle ebuilds with |
| 16 |
> unsupported EAPIs in any way just massively limits what can be done in |
| 17 |
> future EAPIs. |
| 18 |
> |
| 19 |
Em, that's really not what I meant. The main problem GLEP 55 describes is |
| 20 |
that with the current system we're limited to changes which don't break |
| 21 |
sourcing the ebuild (since if it would break sourcing we couldn't even find |
| 22 |
out the ebuild's EAPI version and therefore not whether the currently used |
| 23 |
package manager can handle that ebuild). |
| 24 |
That package managers can't do anything else than masking ebuilds with |
| 25 |
unsupported EAPIs is clear. |
| 26 |
But what I wanted to say is: |
| 27 |
Having the EAPI versioned like this: X.Y where X is the postfix part of the |
| 28 |
ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could |
| 29 |
increment Y in case the changes to the EAPI don't break sourcing (again: a |
| 30 |
package manager will have to mask those ebuilds) while changes breaking the |
| 31 |
sourcing of the ebuild need an increment of X to avoid that pm's not being |
| 32 |
able to even source such an ebuild still can mask it properly (or just |
| 33 |
ignore it). |
| 34 |
|
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@l.g.o mailing list |
Archives