1 |
On Wednesday 27 of April 2011 19:46:21 Ciaran McCreesh wrote: |
2 |
> On Wed, 27 Apr 2011 19:40:47 +0200 |
3 |
|
4 |
> Maciej Mrozowski <reavertm@×××××.com> wrote: |
5 |
> > I'd say using "in some ancient portage" argument all over again to |
6 |
> > reinforce particular point of view is not valid. |
7 |
> |
8 |
> Uh, no, that's the entire point of EAPIs. |
9 |
|
10 |
This is a common misconception. |
11 |
|
12 |
The entire and only point of EAPI is to provide ebuild API - for ebuild |
13 |
developers and for package manager developers. |
14 |
|
15 |
From user point of view - user is required to update package manager (it's the |
16 |
case with portage anyway) to the latest supported version and package manager |
17 |
itself (along with package tree) needs to support such migration path (of |
18 |
course within reasonable timespan - there is catch whether pre-EAPI-2 support |
19 |
is reasonable, python eclass problem). |
20 |
|
21 |
From ebuild developer point of view - EAPI specification should provide all |
22 |
knowledge required to create ebuilds along with detailed and unambiguous |
23 |
description of what to expect from package manager that is compliant with said |
24 |
EAPI. Old package managers and their expected behaviour is irrelevant as soon |
25 |
as migration path to recent version exists for them. That being said this |
26 |
argument blocking the update of specification because of the hypothetical |
27 |
existence of unsupported package manager instances (like ancient |
28 |
portage/paludis/pkgcore versions) is invalid. |
29 |
|
30 |
From package manager developer point of view - EAPI specification should |
31 |
provide all knowledge required to build own package manager compliant with |
32 |
said EAPI, describing its *intended* (and of course being in effect, not just |
33 |
intended) behaviour in detailed and unambiguous way. And here again, old |
34 |
package managers and their provided behaviour is irrelevant as soon as |
35 |
migration path exists for them. |
36 |
|
37 |
Since intended behaviour for normal vs strong blocks is like Ulrich specified, |
38 |
and migration path to the most recent from first portage supporting EAPI-2 |
39 |
exists - argument to block specification update is invalid. |
40 |
|
41 |
EAPI specification is not "what used to be", it's "what is and what can be |
42 |
relied upon", it's that simple. |
43 |
|
44 |
-- |
45 |
regards |
46 |
MM |