1 |
Hi all, |
2 |
|
3 |
after the recent discussion about eclass versioning, possible flaws in |
4 |
eclass signing/authentication I'd like to see eclass versioning |
5 |
implemented. This will hopefully reduce some frustrating bugs and |
6 |
consistency problems, but will cause a bit more work for the maintainers |
7 |
and some small additions to portage. |
8 |
|
9 |
To get a consistent versioning scheme, I suggest |
10 |
blah-{major}.{minor}.eclass |
11 |
as default naming. That way, one could just inherit blah (as-is |
12 |
baheviour), but also inherit blah-3 or blah-4.12 |
13 |
That way, "incompatible" changes in eclasses can be handled by only |
14 |
inheriting the newer eclasses. Also, updates in eclasses can be found |
15 |
very easily so that a consistent build environment is easier to achieve. |
16 |
("Why did it break? building $foo worked yesterday, and all ebuilds are |
17 |
the same ... !?!?") |
18 |
|
19 |
A "grep -r inherit" in /usr/portage shows ~11.5k files which might be |
20 |
affected by changes. The migration can be slow (only add versionated |
21 |
inherit to newer ebuilds) or disruptive (run sed over the whole tree and |
22 |
get tortures because you forgot one special case). |
23 |
Getting it integrated might be possible by a symlink hierarchy similar |
24 |
to the .so versioning in linux, e.g. blah symlinks to blah-3 which in |
25 |
turn symlinks to blah-3.14. That would be pretty much backwards |
26 |
compatible, only the symlink managment (updates etc.) might be a bit |
27 |
more difficult (can this be handled by a new eclass.eclass or |
28 |
equivalent?). |
29 |
|
30 |
Any ideas / comments? |
31 |
|
32 |
Thanks, |
33 |
Patrick |