Olivier Galibert <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: > > <!-- EAPI="3" --> > > *Then* would be the time to change the extension. As long as the > ebuild is bash-parseable with an appropriate environment, it doesn't > make sense to change the extension because a env-variable set or a > comment are more natural methods. > > If/when the format changes to something not parseable by bash, then it > will be time to change the extension. And then how to mark > (sub-)version will depend on the chosen new format, in case of xml > that would be the dtd information. > > I suspect the rejection of the extension change will be there as long > as the fundamental format (bash script) doesn't change.
Well said. This is something that I've heard bandied about on IRC now and then, and sounds to me (notably *not* a package manager developer) like a fairly reasonable compromise. To the proponents of GLEP55: Is there some reason that GLEP55 is preferable to this? Are there reasons why a particular filename extension could not apply to a range of EAPIs? Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
