Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Tue, 24 Feb 2009 10:46:30 -0500 > Richard Freeman <ri...@gentoo.org> wrote: > > I will certainly concede that putting it inside the ebuild > > potentially breaks compatibility with existing package managers. > > That is certainly a downside to this approach. However, none of the > > other objections that have been raised appear to hold water. > > ...and it means we can't change name or version rules. > > ...and it means over doubling the best possible time to work out a > dependency tree in the common case where the metadata cache is valid. > > ...and it means we can't make arbitrary format changes.
Those would all land in the category of "backwards compatibility" mentioned below, as they would all break current sourcing rules. > > And if backwards compatibility were a serious issue you could define > > a new ".ebuild2" file spec that incorporates the EAPI inside the > > file and current package managers would ignore it. Then you're not > > changing the file extension every time a new EAPI comes along, and > > the need to do so could be handled via future GLEPs. > > Developers already have to stop and think and consult the conveniently > available table of features for EAPIs. By splitting the EAPI concept > in two you're doubling the amount of data to be learnt. I would think that this is a very small cost, and the benefit would be (I hope) that more people would agree on the solution and then we can go forward. Is that not a valid consideration? -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
signature.asc
Description: PGP signature
