On Sat, 16 May 2009 18:15:58 +0200 Tobias Klausmann <klaus...@gentoo.org> wrote: > On Sat, 16 May 2009, Ciaran McCreesh wrote: > > Tobias Klausmann <klaus...@gentoo.org> wrote: > > > > Yes, those. The current rules include some pointless arbitrary > > > > restrictions that are only there for historical reasons and that > > > > mean people have to mess with convoluted MY_PV things. > > > > > > Still: a sane spec for those plus a sane spec for inside-the-file > > > EAPI specs can be done with/during *one* extension change. > > > > GLEP 55's just one extension change: it moves from .ebuild > > to .ebuild-EAPI. > > 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. > 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. > [0] I see EAPI specification and version-format spec as separate > issues. It's something we can do as an EAPI thing, and by doing so we keep the smooth upgrade path thing. > > > Any further features that mandate a change in filename format? > > > Pile them on. > > > > There probably will be, and we don't know what they all are yet. > > Unfortunately we can't see the future. > > I meant further as in "not discussed yet". 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. 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". -- Ciaran McCreesh
signature.asc
Description: PGP signature
