1 |
On Sun, 20 Sep 2009 18:52:25 +0200 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> > That language really should be in even if kdebuild is turned off, |
4 |
> > especially if we're explicitly stating that src_test is optional. |
5 |
> |
6 |
> Needs to have FEATURES defined first, otherwise we'll be defining a |
7 |
> specific configuration in abstract generalities. |
8 |
|
9 |
We use language like "at user option", without indicating what that |
10 |
user option is. |
11 |
|
12 |
> > I suggest you stop trying to push a political agenda when doing so |
13 |
> > just makes life harder for the people who have to use PMS. |
14 |
> |
15 |
> Uhm what. I thought we had all found an agreement yesterday that |
16 |
> having kdebuild in PMS was a bad thing. If you keep changing your |
17 |
> opinion every day there's no way to have a reasonable discussion. |
18 |
|
19 |
Please point me to where I (who am part of 'all') agreed that. |
20 |
|
21 |
> > Actually, there was a perfectly clean way of doing it, and Zac even |
22 |
> > agreed to do it that way before he went and implemented it |
23 |
> > unconditionally. The change was supposed to be going through as |
24 |
> > part of EAPI 2. |
25 |
> Nah, that makes a huge stinky if you try to upgrade an EAPI0 package |
26 |
> with an EAPI2 package or vice versa. Then you end up with a dozen |
27 |
> potential ways of doing it, choose one randomly and hope that was a |
28 |
> sane decision. |
29 |
> |
30 |
> Having a consistent phase order is the only way to keep things |
31 |
> predictable ... |
32 |
|
33 |
The way that was chosen resulted in things being broken and a mad |
34 |
scramble to fix things. There are at least two ways of doing it in an |
35 |
entirely well defined manner that wouldn't have involved changing any |
36 |
existing packages. |
37 |
|
38 |
> > That's not how the system works. We're supposed to be documenting |
39 |
> > what ebuilds may rely upon from compliant package managers. Since |
40 |
> > there are compliant package managers that use both behaviours, the |
41 |
> > documentation's supposed to reflect that. |
42 |
> Hrm. All versions of all officially supported package managers I can |
43 |
> see use the "newer" behaviour. So the "old" behaviour might be |
44 |
> interesting for historical reasons, but anything currently in use is |
45 |
> forced to rely on the "new" behaviour. |
46 |
|
47 |
That's not how the system works. We don't pretend old behaviour never |
48 |
existed. |
49 |
|
50 |
> > > Feel free to document historic behaviour if you want, but as PMS |
51 |
> > > hasn't documented it before I'd put it in the errata section. |
52 |
> > Doesn't PMS currently document the old way of doing it, not the new |
53 |
> > way? |
54 |
> See, that's what happens when you don't document what is actually |
55 |
> happening. |
56 |
|
57 |
No, it's what happens when you document what happens and then someone |
58 |
goes and changes things to directly violate the specification. |
59 |
|
60 |
> Either way there's a lot that needs to be done until PMS deserves the |
61 |
> S in its name, but it's not hopeless. At least we're noticing the |
62 |
> things it doesn't document or doesn't document correctly quite nicely. |
63 |
|
64 |
Please provide examples of standards that have been retroactively |
65 |
modified after publication to deal with implementations changing |
66 |
behaviour. |
67 |
|
68 |
-- |
69 |
Ciaran McCreesh |