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