1 |
Instead of adding more and more layers to the Gentoo versioning spec to |
2 |
work around insane upstreams, why not put the relative ordering of |
3 |
versions into the ebuilds? |
4 |
|
5 |
Then, a version identifier would just be a unique string. |
6 |
|
7 |
An ebuild would declare which version strings it succeeds. |
8 |
|
9 |
Then even in the case of an upstream that did something stupid, like |
10 |
only releasing versions identified by the git commit ID, the package |
11 |
manager can both: |
12 |
|
13 |
* Use the upstream versioning scheme. |
14 |
|
15 |
* Know which version is "best", by finding a topological ordering on |
16 |
the succession graph. |
17 |
|
18 |
---- mypackage-insaneversionspec1.ebuild ------------------------------- |
19 |
... |
20 |
# This was the first release of the package, so it succeeds nothing. |
21 |
VERSION_SUCCEEDS="" |
22 |
... |
23 |
---- EOF --------------------------------------------------------------- |
24 |
|
25 |
---- mypackage-insaneversionspec2.ebuild ------------------------------- |
26 |
... |
27 |
# This was the second release of the package, so it succeeds the first |
28 |
# version. |
29 |
VERSION_SUCCEEDS="insaneversionspec2" |
30 |
... |
31 |
---- EOF --------------------------------------------------------------- |
32 |
|
33 |
Obviously, the downside of this scheme is that you have to load and |
34 |
parse every ebuild for a given atom, rather than being able to find the |
35 |
best one just by walking the filenames. |
36 |
|
37 |
Taahir Ahmed |