1 |
On Thursday 28 May 2009 01:10:50 Piotr Jaroszyński wrote: |
2 |
|
3 |
> >> |
4 |
> >> How is it one-way exactly? You can do pretty much anything you want in |
5 |
> >> a new EAPI (that's the point). |
6 |
> > |
7 |
> > You cannot undo it. |
8 |
> > |
9 |
> > In other words, you'll have to allow stupid filenames until the end of |
10 |
> > times even if you are quite positively sure that it is, right now, a bad |
11 |
> > idea. |
12 |
> |
13 |
> What do you mean by "allow" exactly? You can put whatever filenames in |
14 |
> the tree currently and package managers ignore them, just as they |
15 |
> would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55 |
16 |
> be accepted, implemented and then undone you would "lose" only |
17 |
> *.ebuild-{EAPIs introduced before undoing}. |
18 |
|
19 |
If you add an unsupported filetype randomly you'll find a few very unhappy |
20 |
people reverting your commit and suggesting that you never do it again. And |
21 |
repoman will tell you not to do such things (assuming that you do use it) |
22 |
|
23 |
Once you GLEP55 it is very difficult to get rid of any problems it might cause |
24 |
without triggering the kind of apocalyptic breakage that it is supposed to |
25 |
avoid. So we should be reasonably certain that it is in fact the best solution |
26 |
and we want to live with it for a long time. |
27 |
|
28 |
But, as people are discussing some interesting new (and some old) concepts |
29 |
that might change things around quite a bit maybe we should wait until we know |
30 |
where we are going before we start changing things we'd revert immediately. |
31 |
|
32 |
> > Not at all. Just an upgrade snapshot so you can get "old" users into a |
33 |
> > known state, then let them upgrade at least the package manager to a |
34 |
> > point where they can use the rest. That snapshot should be seen as a |
35 |
> > transient helper, not as a "release" ... |
36 |
> |
37 |
> So a user n snapshots behind would have to go through various upgrade |
38 |
> paths n times. And if she failed to do it all at once her system would |
39 |
> be left with known bugs and vulnerabilities. Sounds a bit messy to me, |
40 |
> especially as it can be easily avoided (with improved EAPIs - i.e. |
41 |
> g55). |
42 |
It's actually less messy than the current breakage. Just spend a few days in |
43 |
#gentoo and watch people try to upgrade after >1y ... glep55 does nothing at |
44 |
all to help with that, snapshots at least give a consistent state to converge |
45 |
to. E.g. the bash-portage blocker (easily avoided with a snapshot), the "EAPI1 |
46 |
unsupported" blocker (same) etc. etc. |
47 |
|
48 |
Most issues happen because we do not provide an upgrade path, and GLEP55-style |
49 |
changes only motivate more rapid changes that will not make it easier for |
50 |
users to upgrade. It only has the potential to make life easier for those of |
51 |
use living on the bleeding edge and allows to add package formats to the tree |
52 |
that no official package manager supports (do we want that? I vote for no) |
53 |
|
54 |
Added bonus - as soon as you have a snapshot supporting EAPI="wintermute" you |
55 |
can migrate _all_ packages to it without having to keep Python and gcc and |
56 |
stuff as eapi0. Which means we lose some rather naughty restrictions that are |
57 |
in place now (and can easily deprecate older EAPIs too, which is good in terms |
58 |
of complexity) |
59 |
Oh, and you can change the defaults around too because you _know_ that this |
60 |
snapshot and higher can handle this change. |
61 |
|
62 |
I could go on pointing out nice features, but since this isn't a sales |
63 |
brochure I'll just leave it at that and hope someone actually reads this mail |
64 |
before instareplying. |