1 |
On Tue, 13 Nov 2007 16:17:59 -0800 |
2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
3 |
> On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote: |
4 |
> > That was only the case because previously, using new features that |
5 |
> > Portage didn't support would cause horrible breakage. Now, instead, |
6 |
> > the ebuilds show up as being masked. |
7 |
> |
8 |
> ...which is just as good as "broken" when it happens to a new user |
9 |
> first installing Gentoo and wondering why he can't even follow the |
10 |
> directions in the Handbook. |
11 |
|
12 |
...so you just ensure that the handbook tells the user to upgrade the |
13 |
package manager as quickly as possible. |
14 |
|
15 |
> What brought me to bring this up was the mention of changing of |
16 |
> eclasses which support a large number of ebuilds, effectively masking |
17 |
> a significant portion of the tree from our users. Let's say that I |
18 |
> added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 |
19 |
> feature in one of the functions. Guess what? I've now managed to |
20 |
> mask *portage* for users of older portage versions. In fact, I've |
21 |
> managed to mask paludis and pkgcore, too. Yes, this is an extreme |
22 |
> example. Yes, it is completely possible. Yes, that user would be |
23 |
> completely screwed. |
24 |
|
25 |
Uh huh, so if someone does something immensely stupid things go wrong. |
26 |
How is this anything new? |
27 |
|
28 |
> > > Now, this isn't so much of an issue with individual ebuilds, but |
29 |
> > > you're talking about changing how the Java eclasses work, |
30 |
> > > essentially blocking *anyone* using an older portage (including |
31 |
> > > everyone installing from 2007.0 media) from using any package |
32 |
> > > which inherits the eclass. |
33 |
> > |
34 |
> > They just need to upgrade their package manager first. Easy. |
35 |
> |
36 |
> Expecting users to do pretty much anything on their own is broken |
37 |
> behavior and should not be relied on for package manager |
38 |
> compatibility. |
39 |
|
40 |
Eh? We already expect users to do lots on their own. Are you suggesting |
41 |
that we should take over maintaining everyone's system for them? |
42 |
|
43 |
> > A solution with EAPI-agnostic code in foo-common.eclass and |
44 |
> > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably |
45 |
> > more readable and maintainable in most cases. |
46 |
> |
47 |
> Umm... So in the paragraph above, you say an EAPI-specific eclass |
48 |
> isn't a good idea, and here you push it as the proposed solution. |
49 |
> Huh? Consistency, please... |
50 |
|
51 |
Read it (and my explanation of it earlier in the thread) until you |
52 |
understand it. There is nothing consistent in what I'm saying. |
53 |
|
54 |
EAPI specific eclasses are a bad idea. Providing EAPI-agnostic eclasses |
55 |
by way of multiple EAPI-specific shell eclasses is a good idea. |
56 |
|
57 |
> I guess my real point is that we need to be *really* careful when |
58 |
> using this stuff. It is *not* as simple as you make it out to |
59 |
> sound. |
60 |
|
61 |
No no, it is as simple as I make it sound (which isn't simple simple, |
62 |
but it isn't any more complicated than things people have to do |
63 |
already). |
64 |
|
65 |
If people stick to a) the way I described of handling non-trivial |
66 |
eclasses that need to care about EAPIs, b) not using new EAPIs on |
67 |
things that are hard deps of the package manager that aren't already in |
68 |
the stageball and c) not nuking the last EAPI 0 versions of a package, |
69 |
there isn't a problem. |
70 |
|
71 |
In particular, there is absolutely no need to wait for updated stages |
72 |
before using EAPI 1 for non-system packages. There isn't even a need to |
73 |
avoid using EAPI 1 of things that are deps of a package manager, so |
74 |
long as there remain EAPI 0 versions that are sufficient to satisfy the |
75 |
dependencies. |
76 |
|
77 |
For example, you could quite happily mark, say, doxygen 1.5 as EAPI 1, |
78 |
without breaking the upgrade or install path for Paludis. Paludis 0.24 |
79 |
or older Portage would simply select doxygen 1.4 rather than 1.5, and |
80 |
then once you'd upgraded to Paludis 0.26 the doxygen 1.5 update would |
81 |
become available. The problem only occurs if either EAPI 0 versions are |
82 |
nuked or if particular versions are required. |
83 |
|
84 |
> All it takes is one person adding an EAPI into an eclass |
85 |
> somewhere to completely screw over a *huge* number of our users. |
86 |
|
87 |
All it takes is one person making any silly change to an eclass to |
88 |
screw over a huge number of users. |
89 |
|
90 |
> I still think that EAPI should not be allowed to be set in an eclass |
91 |
> globally. All I can see is it causing problems for tons of users who |
92 |
> don't have a clue what is happening to their systems. |
93 |
|
94 |
EAPI *can't* be set in an eclass correctly anyway because EAPI is |
95 |
allowed to (and likely will in the future) change the behaviour of |
96 |
inherit. |
97 |
|
98 |
-- |
99 |
Ciaran McCreesh |