1 |
On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote: |
2 |
|
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 |
But it is. Discussion about blocks is precisely about what is expected package |
21 |
manager behaviour for self-mutual blocks (in EAPI>=2) in such case. And what |
22 |
you propose is 'behaviour is undefined for self-mutual blocks' - if so, why |
23 |
are they permitted by specification and not banned instead? The way you |
24 |
understand the word 'specification' doesn't really allow any specs bugfixes |
25 |
since they would "magically" invalidate any existing implementations, unless |
26 |
there is just one (and actually there *is* just one *supported*) so that |
27 |
specification could be kept in sync with it. |
28 |
|
29 |
How does Paludis handle normal and/or strong self-blocks? And how PkgCore |
30 |
does? Is blocks situation ever going to be clarified/improved in package |
31 |
manager level? What with other PMS issues? |
32 |
No, specification will be out of sync because every single random package |
33 |
manager developer will implement it his/her way, and then claim said package |
34 |
manager is compliant and specification cannot be fixed since it changes |
35 |
behaviour. No, it doesn't change behaviour of any implementation - it will |
36 |
make it possible to determine that some particular implementation is not |
37 |
compliant. It is to mean that some ancient portage is not compliant with |
38 |
hopefully-soon-to-be-updated specification? Yes indeed, that's the result of |
39 |
updating *specification*. Maybe also the point. |
40 |
|
41 |
> From an ebuild developer's point of view, PMS describes (or at least |
42 |
> tries to describe -- the case under discussion here is one where PMS |
43 |
> probably needs fixing) what can and cannot be relied upon from the |
44 |
> package manager. The EAPI feature is used to restrict your ebuild's |
45 |
> availability to *all* package manager versions supporting a particular |
46 |
> set of features. Not "the most recent Portage version". *ALL* versions |
47 |
> of Portage that claim support for the EAPI in question. |
48 |
|
49 |
(I'm tempted to quote some random definition for fun) |
50 |
|
51 |
Ebuild developer looks at PMS through a view called EAPI so ebuild developer |
52 |
is interested in package manager behaviour in said EAPI that's why I said EAPI |
53 |
not PMS. |
54 |
And Portage is frankly the only supported package manager in Gentoo. |
55 |
|
56 |
If one wanted PMS to document behaviour of all known portage/paludis/pkgcore |
57 |
versions in PMS, one would need to be much more specific: what behaviour |
58 |
applies to what versions of particular package manager so that one really |
59 |
knows what can and what cannot be relied upon. |
60 |
|
61 |
But I suppose it's not the point. |
62 |
|
63 |
I thought PMS is specification and not a documentation - hence it should |
64 |
specify (to document would be poor choice of words.. ) intended, widely agreed |
65 |
behaviour and *defined* behaviour so that ebuild developer knows how to write |
66 |
ebuilds that work against PM *compliant* with specification and package |
67 |
manager developer knows how to write *compliant* PM. And because there are |
68 |
many places where PMS is too vague, it misses those goals. |
69 |
|
70 |
> > Old package managers and their expected behaviour is irrelevant as |
71 |
> > soon as migration path to recent version exists for them. |
72 |
> |
73 |
> Again, you are deeply confused. It is required that an upgrade path for |
74 |
> old package managers is kept around for as long as possible by not |
75 |
> using newer EAPIs for certain key system packages. This is entirely |
76 |
> different to what you're saying -- it means that certain packages |
77 |
> should be kept at low EAPIs for as long as possible, not that EAPIs are |
78 |
> whatever the latest Portage version does. |
79 |
|
80 |
No, you're making it up here. |
81 |
|
82 |
> > Since intended behaviour for normal vs strong blocks is like Ulrich |
83 |
> > specified, and migration path to the most recent from first portage |
84 |
> > supporting EAPI-2 exists - argument to block specification update is |
85 |
> > invalid. |
86 |
> |
87 |
> That doesn't follow at all. What happens if someone has an old Portage |
88 |
> installed and the migration path includes things that rely upon a |
89 |
> changed behaviour? |
90 |
|
91 |
It wouldn't be a migration path, would it? |
92 |
|
93 |
> Since you're trying to retroactively define a |
94 |
> particular behaviour for all EAPIs that doesn't match what some old |
95 |
> Portage versions do, your upgrade path is screwed. |
96 |
|
97 |
No, I'm supporting *defining* behaviour as it's intended so that package |
98 |
managers are able to know whether they are correct. You're making all of them |
99 |
correct by explicitly allowing them to do anything here and there - it's not |
100 |
helping. |
101 |
|
102 |
> This sort of thing really should be in the developer quiz. It's too |
103 |
> basic and fundamental for people to be getting wrong. |
104 |
|
105 |
Comprehensive reading is that sort of thing as well. |
106 |
|
107 |
Ulrich: maybe we should consider renaming PMS to PMD? :P |
108 |
|
109 |
(btw, I'm subscribed to this list) |
110 |
|
111 |
-- |
112 |
regards |
113 |
MM |