On Wed, 4 Nov 2009 09:26:10 +0100
Patrick Lauer <patrick@g.o> wrote:

> On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote:
> > On Tue, 3 Nov 2009 23:28:57 +0100
> > 
> > Patrick Lauer <patrick@g.o> wrote:
> > > And then why bother when the tree doesn't reflect PMS.
> > 
> > Maybe if some people would stop ignoring PMS on whim because they don't
> >  agree with something in it this wouldn't be the case.
> 
> Well, we have at least one prior discussion and a year of precedent on the 
> bash 3.0 / 3.2 thing. Since there were no sanctions for doing it, there's no 
> way to break things with it (because you have a recent enough bash guaranteed) 
> and it is very convenient people started using it.
> 
> After a year of use (and getting used more and more) I just don't see how any 
> sane person can think about forbidding it NOW. It's too late. We've moved on. 
> You missed your chance.

Yes, I think we did.  I think any damage that could have been done by people
ignoring policies about sticking to bash 3.0 has been done, and enforcing it
now would be pointless.

That's not to say though that it shouldn't have been enforced.  If anything,
I think this is a textbook example of the kind of corner we paint ourselves
into when people do whatever the fuck they feel like.  In this particular
case, it seems, no real harm was done except some small amount of backwards
compatibility was thrown out the window.  What happens next time?  I'm
surprised you're using this as an example to support your case because if
anything it warns me that we need to be more careful in the future.

> The only reason it was not properly documented in PMS was because the 
> authors didn't agree with it.

Bullshit.  It wasn't documented in PMS because PMS doesn't document user
configuration, because PMS shouldn't document user configuration.  User
configuration is implementation specific.  Do you not realize what a pain in
the ass it would be if we had to do an EAPI bump to slightly change the
semantics of "userpriv" or to change the enabled defaults, not to mention
change any of the environment variables portage uses for configuration?
Making these things independent of the specification allows the package
manager the freedom it needs to make the changes it needs to in order to
continue improving, and frankly, allows other implementations to be something
other than simple portage clones.

And you're still ignoring the fact that this has nothing to do with PMS.  You
have a core portage dev on record, saying "FEATURES are not supposed to have
an effect on the package itself, just how portage handles the package.
Packages behaving differently on certain FEATURES settings are considered
broken by me" back in 2005, before PMS was even a glimmer in an ex-gentoo
dev's eye.

> Well, if everyone else freely ignores it and pointing out that people 
> violating the policy has no response I'll consider that policy inactive.

Then we obviously need more people laying the smack down.
 

-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662