Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@×××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers
Date: Wed, 27 Apr 2011 21:32:10
Message-Id: 201104272330.22347.reavertm@gmail.com
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
[gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers Maciej Mrozowski <reavertm@×××××.com>