Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for > > EAPI=3 etc? That would just be silly and it was the first idea I > > got when I saw the proposal. > > Yes, yes we are. That's just one change, from a static string to a > pattern for a string. > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
It doesn't. I forsee a non-trivial amount of extra work, breakage and pain with a moving extension. And not anywhere near enough benefit in exchange for it. > > Aside from that, one idea that came to me recently was to specify > > per tree what kind of files (version-format-wise, EAPI > > elsewhere[0]) a PM has to expect. Tree distributors (Gentoo > > itself, other similar distros, overlays... ) would be Providing > > that information along a similar route as profiles/repo_name. > > This would also reduce the amount of mixing and matching version > > formats (something undesirable, if you ask me). It would also > > make it easier to take a look at historical (snapshots of) > > repositories. > > It also means an end to nice incremental updates. I think wanting incremental updates for version specs is a dream we should abandon. The ordering issues avoided by doing so would justify it alone, if you ask me. Yes, that means having a flag day for every repository. But since I figure the new spec will be a superset of the old spec, that could be automated. As for EAPI, I feel we agree that it could live inside the file itself under this scheme. My point is this: from experience I suspect having a hard change once and having easy progress on either side of it is preferable to having mid-range complications all the time. > Well, I strongly doubt that anyone's already thought of all the useful > changes we might want to make in the future, so I don't think proposing > a solution that assumes that they have is a good idea. I think it's a river we should think about once we reach it. > Otherwise, in another year or two we'll just be back to "well we need > to change extensions again, but let's just do it as a second one-off > thing". My experience tells me that with proper preparation of *this* change, that can be pushed past the "in the next ten years" mark. And that is close enough to "indefinitely" for me. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."
