On 21/09/2015 21:45, Taahir Ahmed wrote: > > Instead of adding more and more layers to the Gentoo versioning spec to > work around insane upstreams, why not put the relative ordering of > versions into the ebuilds? > > Then, a version identifier would just be a unique string. > > An ebuild would declare which version strings it succeeds.
That won't work too well for the case of earlier versions that receive updates or -r revisions example mysql. 5.5 and 5.6 are both in the tree so when 5.5.46 is released, 5.6.26 would need to have it's VERSION_SUCCEEDS ebuild updated. This leads to an odd situation where a change in one ebuild is reflected in another. To go the route of declaring order in the ebuild, VERSION_PRECEEDS would fit better. Personally the approach that makes most sense to me is to have a spec as simple as possible to cover the majority cases. Most projects are somewhat sane with version numbers, so cover those with a simple spec. Deal with all weird cases using VERSION_PRECEEDS > > Then even in the case of an upstream that did something stupid, like > only releasing versions identified by the git commit ID, the package > manager can both: > > * Use the upstream versioning scheme. > > * Know which version is "best", by finding a topological ordering on > the succession graph. > > ---- mypackage-insaneversionspec1.ebuild ------------------------------- > ... > # This was the first release of the package, so it succeeds nothing. > VERSION_SUCCEEDS="" > ... > ---- EOF --------------------------------------------------------------- > > ---- mypackage-insaneversionspec2.ebuild ------------------------------- > ... > # This was the second release of the package, so it succeeds the first > # version. > VERSION_SUCCEEDS="insaneversionspec2" > ... > ---- EOF --------------------------------------------------------------- > > Obviously, the downside of this scheme is that you have to load and > parse every ebuild for a given atom, rather than being able to find the > best one just by walking the filenames. > > Taahir Ahmed > -- Alan McKinnon alan.mckin...@gmail.com
