1 |
On Wed, 27 Apr 2011 21:09:58 +0200 |
2 |
Maciej Mrozowski <reavertm@×××××.com> wrote: |
3 |
> > Uh, no, that's the entire point of EAPIs. |
4 |
> |
5 |
> This is a common misconception. |
6 |
|
7 |
Uh, no. You are completely and horribly wrong. |
8 |
|
9 |
EAPIs were introduced to avoid the problems that we used to have where |
10 |
different versions of Portage did different things with the same input |
11 |
(including, but not limited to, difficulties in adding new features). |
12 |
|
13 |
> From ebuild developer point of view - EAPI specification should |
14 |
> provide all knowledge required to create ebuilds along with detailed |
15 |
> and unambiguous description of what to expect from package manager |
16 |
> that is compliant with said EAPI. |
17 |
|
18 |
Oh heck no. That really isn't the point at all. |
19 |
|
20 |
From an ebuild developer's point of view, PMS describes (or at least |
21 |
tries to describe -- the case under discussion here is one where PMS |
22 |
probably needs fixing) what can and cannot be relied upon from the |
23 |
package manager. The EAPI feature is used to restrict your ebuild's |
24 |
availability to *all* package manager versions supporting a particular |
25 |
set of features. Not "the most recent Portage version". *ALL* versions |
26 |
of Portage that claim support for the EAPI in question. |
27 |
|
28 |
> Old package managers and their expected behaviour is irrelevant as |
29 |
> soon as migration path to recent version exists for them. |
30 |
|
31 |
Again, you are deeply confused. It is required that an upgrade path for |
32 |
old package managers is kept around for as long as possible by not |
33 |
using newer EAPIs for certain key system packages. This is entirely |
34 |
different to what you're saying -- it means that certain packages |
35 |
should be kept at low EAPIs for as long as possible, not that EAPIs are |
36 |
whatever the latest Portage version does. |
37 |
|
38 |
> Since intended behaviour for normal vs strong blocks is like Ulrich |
39 |
> specified, and migration path to the most recent from first portage |
40 |
> supporting EAPI-2 exists - argument to block specification update is |
41 |
> invalid. |
42 |
|
43 |
That doesn't follow at all. What happens if someone has an old Portage |
44 |
installed and the migration path includes things that rely upon a |
45 |
changed behaviour? Since you're trying to retroactively define a |
46 |
particular behaviour for all EAPIs that doesn't match what some old |
47 |
Portage versions do, your upgrade path is screwed. |
48 |
|
49 |
This sort of thing really should be in the developer quiz. It's too |
50 |
basic and fundamental for people to be getting wrong. |
51 |
|
52 |
-- |
53 |
Ciaran McCreesh |