1 |
2009/5/28 Patrick Lauer <patrick@g.o>: |
2 |
> On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote: |
3 |
>> 2009/5/27 Patrick Lauer <patrick@g.o>: |
4 |
>> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote: |
5 |
>> >> > Gentoo should not repeat the VHS vs Betamax war. For those who do not |
6 |
>> >> > remember, VHS was the better marketed but inferior technical solution |
7 |
>> >> > that won the standards war for domestic Video recorders. |
8 |
>> >> > |
9 |
>> >> :) Yep. And bad design decisions can haunt is for a long time. |
10 |
>> > |
11 |
>> > Actually, once we add the current-glep55 changes we have no way of sanely |
12 |
>> > undoing them if we should realize that they don't work out for us ... |
13 |
>> > |
14 |
>> > ... unless we do horrible things like forbidding it, which would cause |
15 |
>> > the same errors we are trying to hide now. |
16 |
>> > |
17 |
>> > So unless we have a plan for mid-term future changes I don't see why we |
18 |
>> > would want the current GLEP55 - it's a one-way change in the current |
19 |
>> > state. |
20 |
>> |
21 |
>> How is it one-way exactly? You can do pretty much anything you want in |
22 |
>> a new EAPI (that's the point). |
23 |
> |
24 |
> You cannot undo it. |
25 |
> |
26 |
> In other words, you'll have to allow stupid filenames until the end of times |
27 |
> even if you are quite positively sure that it is, right now, a bad idea. |
28 |
|
29 |
What do you mean by "allow" exactly? You can put whatever filenames in |
30 |
the tree currently and package managers ignore them, just as they |
31 |
would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55 |
32 |
be accepted, implemented and then undone you would "lose" only |
33 |
*.ebuild-{EAPIs introduced before undoing}. |
34 |
|
35 |
>> >> My preference is the one-time .ebuild->.eb change, and putting the EAPI |
36 |
>> >> on the first line, like a #!shebang. Very easy to extract, and good |
37 |
>> >> design. |
38 |
>> > |
39 |
>> > My preference is freezing the rsync tree, storing all referenced |
40 |
>> > distfiles on at least one mirror, then change the rsync path. |
41 |
>> > That way all "old" users get the last sane upgrade position (...) |
42 |
>> |
43 |
>> And bugs and security vulnerabilities too. Or do you propose |
44 |
>> maintaining multiple trees at the same time? I think one of the main |
45 |
>> points of EAPI was to avoid doing exactly that. |
46 |
> |
47 |
> Not at all. Just an upgrade snapshot so you can get "old" users into a known |
48 |
> state, then let them upgrade at least the package manager to a point where |
49 |
> they can use the rest. That snapshot should be seen as a transient helper, not |
50 |
> as a "release" ... |
51 |
|
52 |
So a user n snapshots behind would have to go through various upgrade |
53 |
paths n times. And if she failed to do it all at once her system would |
54 |
be left with known bugs and vulnerabilities. Sounds a bit messy to me, |
55 |
especially as it can be easily avoided (with improved EAPIs - i.e. |
56 |
g55). |
57 |
|
58 |
-- |
59 |
Best Regards, |
60 |
Piotr Jaroszyński |