2008/6/9 Tiziano Müller <[EMAIL PROTECTED]>: > Ciaran McCreesh wrote: > >> On Mon, 09 Jun 2008 10:27:56 +0200 >> Tiziano Müller <[EMAIL PROTECTED]> wrote: >>> Ciaran McCreesh wrote: >>> > No point. A 0 package manager still couldn't use a 0.1 ebuild. >>> > >>> That's true, it has at least to be aware the there's an EAPI. >>> But how does such a package manager handle .ebuild-0 files? Ignore >>> them? Failing because of unknown files in a package-dir? >>> Should we care about package managers not being aware of the >>> existence of EAPI's? >> >> Package managers can't do *anything* with ebuilds with unsupported >> EAPIs anyway. Encouraging package managers to handle ebuilds with >> unsupported EAPIs in any way just massively limits what can be done in >> future EAPIs. >> > Em, that's really not what I meant. The main problem GLEP 55 describes is > that with the current system we're limited to changes which don't break > sourcing the ebuild (since if it would break sourcing we couldn't even find > out the ebuild's EAPI version and therefore not whether the currently used > package manager can handle that ebuild). > That package managers can't do anything else than masking ebuilds with > unsupported EAPIs is clear. > But what I wanted to say is: > Having the EAPI versioned like this: X.Y where X is the postfix part of the > ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could > increment Y in case the changes to the EAPI don't break sourcing (again: a > package manager will have to mask those ebuilds) while changes breaking the > sourcing of the ebuild need an increment of X to avoid that pm's not being > able to even source such an ebuild still can mask it properly (or just > ignore it).
What's the point of sourcing an ebuild that cannot be used anyway? -- Best Regards, Piotr Jaroszyński
