1 |
On Wed, 4 Nov 2009 09:26:10 +0100 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
|
4 |
> On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote: |
5 |
> > On Tue, 3 Nov 2009 23:28:57 +0100 |
6 |
> > |
7 |
> > Patrick Lauer <patrick@g.o> wrote: |
8 |
> > > And then why bother when the tree doesn't reflect PMS. |
9 |
> > |
10 |
> > Maybe if some people would stop ignoring PMS on whim because they don't |
11 |
> > agree with something in it this wouldn't be the case. |
12 |
> |
13 |
> Well, we have at least one prior discussion and a year of precedent on the |
14 |
> bash 3.0 / 3.2 thing. Since there were no sanctions for doing it, there's no |
15 |
> way to break things with it (because you have a recent enough bash guaranteed) |
16 |
> and it is very convenient people started using it. |
17 |
> |
18 |
> After a year of use (and getting used more and more) I just don't see how any |
19 |
> sane person can think about forbidding it NOW. It's too late. We've moved on. |
20 |
> You missed your chance. |
21 |
|
22 |
Yes, I think we did. I think any damage that could have been done by people |
23 |
ignoring policies about sticking to bash 3.0 has been done, and enforcing it |
24 |
now would be pointless. |
25 |
|
26 |
That's not to say though that it shouldn't have been enforced. If anything, |
27 |
I think this is a textbook example of the kind of corner we paint ourselves |
28 |
into when people do whatever the fuck they feel like. In this particular |
29 |
case, it seems, no real harm was done except some small amount of backwards |
30 |
compatibility was thrown out the window. What happens next time? I'm |
31 |
surprised you're using this as an example to support your case because if |
32 |
anything it warns me that we need to be more careful in the future. |
33 |
|
34 |
> The only reason it was not properly documented in PMS was because the |
35 |
> authors didn't agree with it. |
36 |
|
37 |
Bullshit. It wasn't documented in PMS because PMS doesn't document user |
38 |
configuration, because PMS shouldn't document user configuration. User |
39 |
configuration is implementation specific. Do you not realize what a pain in |
40 |
the ass it would be if we had to do an EAPI bump to slightly change the |
41 |
semantics of "userpriv" or to change the enabled defaults, not to mention |
42 |
change any of the environment variables portage uses for configuration? |
43 |
Making these things independent of the specification allows the package |
44 |
manager the freedom it needs to make the changes it needs to in order to |
45 |
continue improving, and frankly, allows other implementations to be something |
46 |
other than simple portage clones. |
47 |
|
48 |
And you're still ignoring the fact that this has nothing to do with PMS. You |
49 |
have a core portage dev on record, saying "FEATURES are not supposed to have |
50 |
an effect on the package itself, just how portage handles the package. |
51 |
Packages behaving differently on certain FEATURES settings are considered |
52 |
broken by me" back in 2005, before PMS was even a glimmer in an ex-gentoo |
53 |
dev's eye. |
54 |
|
55 |
> Well, if everyone else freely ignores it and pointing out that people |
56 |
> violating the policy has no response I'll consider that policy inactive. |
57 |
|
58 |
Then we obviously need more people laying the smack down. |
59 |
|
60 |
|
61 |
-- |
62 |
fonts, Character is what you are in the dark. |
63 |
gcc-porting, |
64 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |