On Wed, 4 Nov 2009 09:26:10 +0100 Patrick Lauer wrote: > On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote: > > On Tue, 3 Nov 2009 23:28:57 +0100 > > > > Patrick Lauer 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