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).
-- gentoo-dev@lists.gentoo.org mailing list
