1 |
On Monday 02 of May 2011 03:41:43 Brian Harring wrote: |
2 |
> On Wed, Apr 27, 2011 at 11:34:00PM +0200, Maciej Mrozowski wrote: |
3 |
> > On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote: |
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 |
And wrt blocks it would still work. It's not like clarifying self-mutual |
31 |
blocks semantics would magically alter behaviour with regards to how the |
32 |
package is merged. It may only have consequences on package set level, not |
33 |
ebuild level. But then again, IIRC Paludis still doesn't perform auto- |
34 |
unmerging of not referenced soft-blocked packages and it's being extensively |
35 |
used in gentoo-x86 tree and I see nobody screaming... |
36 |
(this may have changed however, my point is invalid if that's the case) |
37 |
|
38 |
> Not saying it was done *perfectly*, but this is a large part of it's |
39 |
> intent. |
40 |
> |
41 |
> > > > From ebuild developer point of view - EAPI specification should |
42 |
> > > > provide all knowledge required to create ebuilds along with detailed |
43 |
> > > > and unambiguous description of what to expect from package manager |
44 |
> > > > that is compliant with said EAPI. |
45 |
> > > |
46 |
> > > Oh heck no. That really isn't the point at all. |
47 |
> > |
48 |
> > But it is. Discussion about blocks is precisely about what is expected |
49 |
> > package manager behaviour for self-mutual blocks (in EAPI>=2) in such |
50 |
> > case. And what you propose is 'behaviour is undefined for self-mutual |
51 |
> > blocks' - if so, why are they permitted by specification and not banned |
52 |
> > instead? The way you understand the word 'specification' doesn't really |
53 |
> > allow any specs bugfixes since they would "magically" invalidate any |
54 |
> > existing implementations, unless there is just one (and actually there |
55 |
> > *is* just one *supported*) so that specification could be kept in sync |
56 |
> > with it. |
57 |
> |
58 |
> Ciaran's coming at this from the academic definition of |
59 |
> "specification". In a perfect world, it's correct- once a spec is |
60 |
> stabled, it's immutable sans clarifying wording/intent, and even that |
61 |
> involves occasionally converting bad parts of the spec to unspecified |
62 |
> (or unspecified if a large PM screwed up their implementation badly |
63 |
> enough you can't rely on that assertion any longer). |
64 |
> |
65 |
> Pragmatism is such that bugfixes/tweaks do get pushed in where |
66 |
> required, and where it doesn't fuck us hard to do so. |
67 |
> |
68 |
> As for *why* they're allowed in the first place, it's because the spec |
69 |
> is incomplete- it has a large number of assertions, but covering all |
70 |
> of it is fairly hard (and questionable in usefulness for certain |
71 |
> spots)- I generally hate 'unspecified', but the primary usefullness is |
72 |
> to make clear that proceeding behaviour could vary across PMs- |
73 |
> specifically it should be used when |
74 |
> |
75 |
> > I thought PMS is specification and not a documentation - hence it should |
76 |
> > specify (to document would be poor choice of words.. ) intended, widely |
77 |
> > agreed behaviour and *defined* behaviour so that ebuild developer knows |
78 |
> > how to write ebuilds that work against PM *compliant* with specification |
79 |
> > and package manager developer knows how to write *compliant* PM. And |
80 |
> > because there are many places where PMS is too vague, it misses those |
81 |
> > goals. |
82 |
> |
83 |
> Asserting all behaviour is actually fairly hard. Patches welcome for |
84 |
> that intent, but additions to the spec have to be written to avoid |
85 |
> breaking previous assertions in the spec- as said, a portage that was |
86 |
> EAPI2 compliant 2 years back needs to work with ebuilds that EAPI2 |
87 |
> from today. |
88 |
> |
89 |
> It sucks, but this is /proper/ versioning. It's a hard problem. |
90 |
> |
91 |
> > > > Old package managers and their expected behaviour is irrelevant as |
92 |
> > > > soon as migration path to recent version exists for them. |
93 |
> > > |
94 |
> > > Again, you are deeply confused. It is required that an upgrade path for |
95 |
> > > old package managers is kept around for as long as possible by not |
96 |
> > > using newer EAPIs for certain key system packages. This is entirely |
97 |
> > > different to what you're saying -- it means that certain packages |
98 |
> > > should be kept at low EAPIs for as long as possible, not that EAPIs are |
99 |
> > > whatever the latest Portage version does. |
100 |
> > |
101 |
> > No, you're making it up here. |
102 |
> |
103 |
> This is actually required. Abided by? Not as well as it should |
104 |
> (python has been fucking that one up hard), but take a look at glibc's |
105 |
> eapi, gcc, binutils... etc. |
106 |
> |
107 |
> This is *exactly* what we intended when EAPI was added 5.5 years ago |
108 |
> (and was the intent for the year or so before a patch got pushed in). |
109 |
> |
110 |
> > > > Since intended behaviour for normal vs strong blocks is like Ulrich |
111 |
> > > > specified, and migration path to the most recent from first portage |
112 |
> > > > supporting EAPI-2 exists - argument to block specification update is |
113 |
> > > > invalid. |
114 |
> > > |
115 |
> > > That doesn't follow at all. What happens if someone has an old Portage |
116 |
> > > installed and the migration path includes things that rely upon a |
117 |
> > > changed behaviour? |
118 |
> > |
119 |
> > It wouldn't be a migration path, would it? |
120 |
> |
121 |
> You're proving his point. |
122 |
|
123 |
Not necessarily. |
124 |
Migration path to the version of <insert your favourite package manager here> |
125 |
that is compliant with updated specification doesn't have to involve relying |
126 |
on changed behaviour (changed at this point only in specification since old |
127 |
package manager is being used to update to the newer one after all). |
128 |
|
129 |
And why do I argue on effectively dropping support for older versions and to |
130 |
keep specification in sync with the latest version as much as possible (across |
131 |
package managers)? |
132 |
|
133 |
Maintenance cost. |
134 |
Every new EAPI requires added codepaths and it adds potential complexity if |
135 |
for instance dependency resolver behaviour is altered. If every little |
136 |
specification cleanup was conducted by bumping EAPI, it would lead to |
137 |
unmaintainable code (I know people like spaghetti though). |
138 |
Well, just look at portage - only few are brave enough to touch it and even |
139 |
fewer know how it really works. |
140 |
And since Gentoo lives in $0 budget working environment, resource constrains |
141 |
(time * manpower) should be considered. Since there's no budget for rewrite, |
142 |
we should simplify instead. |
143 |
|
144 |
> > > Since you're trying to retroactively define a |
145 |
> > > particular behaviour for all EAPIs that doesn't match what some old |
146 |
> > > Portage versions do, your upgrade path is screwed. |
147 |
> > |
148 |
> > No, I'm supporting *defining* behaviour as it's intended so that package |
149 |
> > managers are able to know whether they are correct. You're making all of |
150 |
> > them correct by explicitly allowing them to do anything here and there - |
151 |
> > it's not helping. |
152 |
> |
153 |
> What you're not getting is proper format support. Yes, there are |
154 |
> areas in eapi0, 1, 2, etc, that I'd *love* to go back and make a |
155 |
> clearer definition on- the problem is ensuring that all versions of |
156 |
> portage/pkgcore/paludis that supported those EAPI's are still |
157 |
> compliant. If that can be assured, then, within limits, we can |
158 |
> redefine previous EAPIs- because effectively we're not actually |
159 |
> defining any *new* behaviour, just clarifying old behaviour that |
160 |
> happily matches what we want now. |
161 |
> |
162 |
> If those things hold, we can't do it, and that's a fact of defining |
163 |
> versioned formats. |
164 |
> |
165 |
> > Ulrich: maybe we should consider renaming PMS to PMD? :P |
166 |
> |
167 |
> It certainly would be nice being able to avoid stating "active in |
168 |
> gentoo's PMS process" for folks resumes, I must say (which is where a |
169 |
> lot of the juvenile humour derives from I suspect). |
170 |
|
171 |
Missed. I never meant to state I was active in Gentoo PMS process, "we" comes |
172 |
from wearing certain hat if it wasn't clear enough (that being said I just |
173 |
prefer not to use @gentoo.org in mailing lists just to observe how people |
174 |
react to "third-parties"). |
175 |
|
176 |
> So... rather than continuing to argue about what EAPI was intended |
177 |
> for, lets switch back to whether or not we can clarify the rules for |
178 |
> self blockers in existing EAPIs, and what we'd like it to be for |
179 |
> >=EAPI5.. |
180 |
|
181 |
Yes. |
182 |
The problem is that person most interested in participating in such |
183 |
discussion, the one solely responsible for reference and supported package |
184 |
manager implementation (for Gentoo) is Zac, but he's not interested in (or |
185 |
doesn't have time for) bickering with Ciaran (who apparently does have time) |
186 |
and I don't blame him at all frankly (I don't blame Ciaran either, he could |
187 |
just try to avoid stating his opinion on how broken Portage is on every single |
188 |
occasion he has like anyone even cared.. and send patches instead). |
189 |
|
190 |
Anyway Ciaran diverged discussion to what's the purpose of EAPI and what's |
191 |
not. Not sure what's the time line for "in the old days Portage treated all |
192 |
blockers as being a bit like what strong blockers are now" is, to my knowledge |
193 |
in all Portage versions supporting EAPI-2 this behaviour is consistent, well- |
194 |
defined and as such could be documented as in effect for >=EAPI-2 (with |
195 |
possible altering in EAPI-5 - for instance non-strong self-blocks forbidden or |
196 |
sth) |
197 |
|
198 |
-- |
199 |
regards |
200 |
MM |