Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Alan McKinnon]

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.mckinnon@×××××.com