Gentoo Archives: gentoo-pms

From: Patrick Lauer <patrick@g.o>
To: gentoo-pms@l.g.o
Cc: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Subject: Re: [gentoo-pms] Small cleanup of ebuild-functions.tex
Date: Sun, 20 Sep 2009 16:52:24
Message-Id: 200909201852.25856.patrick@gentoo.org
In Reply to: Re: [gentoo-pms] Small cleanup of ebuild-functions.tex by Ciaran McCreesh
1 On Sunday 20 September 2009 18:34:12 Ciaran McCreesh wrote:
2 > On Sun, 20 Sep 2009 18:21:48 +0200
3 >
4 > Patrick Lauer <patrick@g.o> wrote:
5 > > > > First change: the test phase is only run when enabled. Since PMS
6 > > > > doesn't document FEATURES yet we can only say "if tests are
7 > > > > enabled" instead of being more precise. Well, defining FEATURES
8 > > > > shouldn't be too hard, but that's for another day.
9 > > >
10 > > > Please cross-reference that to the part where we explain that
11 > > > src_test is run at user option.
12 > >
13 > > I fail to find such a thing in current PMS.
14 >
15 > Grep for 'src-test-required', and bear in mind what I said about "so
16 > that the user option part is explained even if kdebuild is disabled".
17 Oh. That's well hidden and not visible to the normal reader. You naughty boy!
18
19 > That language really should be in even if kdebuild is turned off,
20 > especially if we're explicitly stating that src_test is optional.
21 Needs to have FEATURES defined first, otherwise we'll be defining a specific
22 configuration in abstract generalities.
23
24 >
25 > > > You might also want to tidy up the language on
26 > > > that so that the user option part is explained even if kdebuild is
27 > > > disabled.
28 > > I suggest we do as you suggested yesterday and remove kdebuild
29 > > unconditionally. That saves hacking around something that cannot be
30 > > in the final version anyway.
31 > I suggest you stop trying to push a political agenda when doing so just
32 > makes life harder for the people who have to use PMS.
33 Uhm what. I thought we had all found an agreement yesterday that having
34 kdebuild in PMS was a bad thing. If you keep changing your opinion every day
35 there's no way to have a reasonable discussion.
36
37
38 > > > Actually, this one's a bit of a mess, thanks to Portage making a
39 > > > non-EAPI-controlled order change that was supposed to go in in EAPI
40 > > > 2 but didn't.
41 > >
42 > > Yeah, messy thing. But as you are well aware there was no sane way to
43 > > make that change EAPI-dependant without causing ambiguous situation
44 > > and much more confusion.
45 >
46 > Actually, there was a perfectly clean way of doing it, and Zac even
47 > agreed to do it that way before he went and implemented it
48 > unconditionally. The change was supposed to be going through as part of
49 > EAPI 2.
50 Nah, that makes a huge stinky if you try to upgrade an EAPI0 package with an
51 EAPI2 package or vice versa. Then you end up with a dozen potential ways of
52 doing it, choose one randomly and hope that was a sane decision.
53
54 Having a consistent phase order is the only way to keep things predictable ...
55
56 > That's not how the system works. We're supposed to be documenting what
57 > ebuilds may rely upon from compliant package managers. Since there are
58 > compliant package managers that use both behaviours, the
59 > documentation's supposed to reflect that.
60 Hrm. All versions of all officially supported package managers I can see use
61 the "newer" behaviour. So the "old" behaviour might be interesting for
62 historical reasons, but anything currently in use is forced to rely on the
63 "new" behaviour.
64
65
66 > > Feel free to document historic behaviour if you want, but as PMS
67 > > hasn't documented it before I'd put it in the errata section.
68 > Doesn't PMS currently document the old way of doing it, not the new way?
69 See, that's what happens when you don't document what is actually happening.
70 Now you are confused, I'm slightly confused and we can't even discuss basic
71 things anymore.
72
73 As far as I can tell current PMS documents the new behaviour. At least that's
74 the impression I get from comparing older versions of it to the current state
75 and looking at previous discussions. Unless I got things backwards again
76 because they aren't documented properly.
77
78 Either way there's a lot that needs to be done until PMS deserves the S in its
79 name, but it's not hopeless. At least we're noticing the things it doesn't
80 document or doesn't document correctly quite nicely.

Replies

Subject Author
Re: [gentoo-pms] Small cleanup of ebuild-functions.tex Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>