1 |
On Wed, Apr 27, 2011 at 11:34:00PM +0200, Maciej Mrozowski wrote: |
2 |
> On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote: |
3 |
> |
4 |
> > > > Uh, no, that's the entire point of EAPIs. |
5 |
> > > |
6 |
> > > This is a common misconception. |
7 |
> > |
8 |
> > Uh, no. You are completely and horribly wrong. |
9 |
> |
10 |
> > EAPIs were introduced to avoid the problems that we used to have where |
11 |
> > different versions of Portage did different things with the same input |
12 |
> > (including, but not limited to, difficulties in adding new features). |
13 |
|
14 |
To be clear, Ciaran is very much correct here- I added EAPI in to |
15 |
fix ongoing shit like this where overlays/old ebuilds in the |
16 |
tree would be broken via the latest/greatest insanity portage leveled, |
17 |
and to allow new ebuild functionality to roll out quickly instead of |
18 |
having to sit for at least a year. |
19 |
|
20 |
This is *exactly* the point of EAPI- it's format versioning for |
21 |
compatibility. As such once a version is considered "released" or |
22 |
"stable", it's basically immutable. |
23 |
|
24 |
EAPI was explicitly designed to allow a portage from 2 years back to |
25 |
be able to function w/ ebuilds written to that EAPI- assuming the |
26 |
version of portage in use was compliant w/ the EAPI2 (from 2 years |
27 |
back), it should still function w/ ebuilds written in current times |
28 |
that are EAPI2. |
29 |
|
30 |
Not saying it was done *perfectly*, but this is a large part of it's |
31 |
intent. |
32 |
|
33 |
|
34 |
> > > From ebuild developer point of view - EAPI specification should |
35 |
> > > provide all knowledge required to create ebuilds along with detailed |
36 |
> > > and unambiguous description of what to expect from package manager |
37 |
> > > that is compliant with said EAPI. |
38 |
> > |
39 |
> > Oh heck no. That really isn't the point at all. |
40 |
> |
41 |
> But it is. Discussion about blocks is precisely about what is expected package |
42 |
> manager behaviour for self-mutual blocks (in EAPI>=2) in such case. And what |
43 |
> you propose is 'behaviour is undefined for self-mutual blocks' - if so, why |
44 |
> are they permitted by specification and not banned instead? The way you |
45 |
> understand the word 'specification' doesn't really allow any specs bugfixes |
46 |
> since they would "magically" invalidate any existing implementations, unless |
47 |
> there is just one (and actually there *is* just one *supported*) so that |
48 |
> specification could be kept in sync with it. |
49 |
|
50 |
Ciaran's coming at this from the academic definition of |
51 |
"specification". In a perfect world, it's correct- once a spec is |
52 |
stabled, it's immutable sans clarifying wording/intent, and even that |
53 |
involves occasionally converting bad parts of the spec to unspecified |
54 |
(or unspecified if a large PM screwed up their implementation badly |
55 |
enough you can't rely on that assertion any longer). |
56 |
|
57 |
Pragmatism is such that bugfixes/tweaks do get pushed in where |
58 |
required, and where it doesn't fuck us hard to do so. |
59 |
|
60 |
As for *why* they're allowed in the first place, it's because the spec |
61 |
is incomplete- it has a large number of assertions, but covering all |
62 |
of it is fairly hard (and questionable in usefulness for certain |
63 |
spots)- I generally hate 'unspecified', but the primary usefullness is |
64 |
to make clear that proceeding behaviour could vary across PMs- |
65 |
specifically it should be used when |
66 |
|
67 |
> I thought PMS is specification and not a documentation - hence it should |
68 |
> specify (to document would be poor choice of words.. ) intended, widely agreed |
69 |
> behaviour and *defined* behaviour so that ebuild developer knows how to write |
70 |
> ebuilds that work against PM *compliant* with specification and package |
71 |
> manager developer knows how to write *compliant* PM. And because there are |
72 |
> many places where PMS is too vague, it misses those goals. |
73 |
|
74 |
Asserting all behaviour is actually fairly hard. Patches welcome for |
75 |
that intent, but additions to the spec have to be written to avoid |
76 |
breaking previous assertions in the spec- as said, a portage that was |
77 |
EAPI2 compliant 2 years back needs to work with ebuilds that EAPI2 |
78 |
from today. |
79 |
|
80 |
It sucks, but this is /proper/ versioning. It's a hard problem. |
81 |
|
82 |
|
83 |
> > > Old package managers and their expected behaviour is irrelevant as |
84 |
> > > soon as migration path to recent version exists for them. |
85 |
> > |
86 |
> > Again, you are deeply confused. It is required that an upgrade path for |
87 |
> > old package managers is kept around for as long as possible by not |
88 |
> > using newer EAPIs for certain key system packages. This is entirely |
89 |
> > different to what you're saying -- it means that certain packages |
90 |
> > should be kept at low EAPIs for as long as possible, not that EAPIs are |
91 |
> > whatever the latest Portage version does. |
92 |
> |
93 |
> No, you're making it up here. |
94 |
|
95 |
This is actually required. Abided by? Not as well as it should |
96 |
(python has been fucking that one up hard), but take a look at glibc's |
97 |
eapi, gcc, binutils... etc. |
98 |
|
99 |
This is *exactly* what we intended when EAPI was added 5.5 years ago |
100 |
(and was the intent for the year or so before a patch got pushed in). |
101 |
|
102 |
|
103 |
> > > Since intended behaviour for normal vs strong blocks is like Ulrich |
104 |
> > > specified, and migration path to the most recent from first portage |
105 |
> > > supporting EAPI-2 exists - argument to block specification update is |
106 |
> > > invalid. |
107 |
> > |
108 |
> > That doesn't follow at all. What happens if someone has an old Portage |
109 |
> > installed and the migration path includes things that rely upon a |
110 |
> > changed behaviour? |
111 |
> |
112 |
> It wouldn't be a migration path, would it? |
113 |
|
114 |
You're proving his point. |
115 |
|
116 |
|
117 |
> > Since you're trying to retroactively define a |
118 |
> > particular behaviour for all EAPIs that doesn't match what some old |
119 |
> > Portage versions do, your upgrade path is screwed. |
120 |
> |
121 |
> No, I'm supporting *defining* behaviour as it's intended so that package |
122 |
> managers are able to know whether they are correct. You're making all of them |
123 |
> correct by explicitly allowing them to do anything here and there - it's not |
124 |
> helping. |
125 |
|
126 |
What you're not getting is proper format support. Yes, there are |
127 |
areas in eapi0, 1, 2, etc, that I'd *love* to go back and make a |
128 |
clearer definition on- the problem is ensuring that all versions of |
129 |
portage/pkgcore/paludis that supported those EAPI's are still |
130 |
compliant. If that can be assured, then, within limits, we can |
131 |
redefine previous EAPIs- because effectively we're not actually |
132 |
defining any *new* behaviour, just clarifying old behaviour that |
133 |
happily matches what we want now. |
134 |
|
135 |
If those things hold, we can't do it, and that's a fact of defining |
136 |
versioned formats. |
137 |
|
138 |
|
139 |
> Ulrich: maybe we should consider renaming PMS to PMD? :P |
140 |
|
141 |
It certainly would be nice being able to avoid stating "active in |
142 |
gentoo's PMS process" for folks resumes, I must say (which is where a |
143 |
lot of the juvenile humour derives from I suspect). |
144 |
|
145 |
So... rather than continuing to argue about what EAPI was intended |
146 |
for, lets switch back to whether or not we can clarify the rules for |
147 |
self blockers in existing EAPIs, and what we'd like it to be for |
148 |
>=EAPI5.. |
149 |
|
150 |
~harring |