| 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 |
Archives