On Thursday 23 June 2011 23:06:00 Neil Bothwick did opine thusly: > > > b) it breaks the way portage displays his informations. > > > Without > > > autounmask the display of emerge shows what he is going to > > > do. With autounmask it shows what needs to be done. > > > > > > > > That is probably the most evil of all your reasons. There's an > > old dev joke about The Law Of Unintended Consequences, and it > > applies here - portage is now suddenly doing something new and > > 180 different from what it used to do. The normal response if > > "WTF?" followed by lots of indignation > > Ah, the old "we do it that way because that's the way it's always > been done" argument. Yes, it is different, yes, it may be confusing > when you first encounter the change - but that doesn't make it bad.
The thing itself is neither inherently good nor bad. Implementing it in this way is bad. Why? Because the behaviour changed to something that is the exact opposite without any warning. Portage always used to tell what it will do. Now, simply by leaving the relevant options at the default, it tells me what it should do. How much more contrary to reasonable expectation can you get? Imagine if tcpwrappers did this. Imagine that hosts.deny was dropped and hosts.allow retained, also imagine that the desired config file name becomes hosts.tcpd but it will use hosts.allow if hosts.tcpd is not found. Now also imagine that the default interpretation of hosts.tcpd is now default deny, explicit allow. All your rules now suddenly invert. Chaos ensues. Sure, it's a contrived example, but it's also a very good example of why one never suddenly and without warning changes default behaviour to the opposite. Few people will argue against the existence of the new unmask options. Folk who want it can use it. Just don't make it the default in such a way that it catches old time users by surprise. -- alan dot mckinnon at gmail dot com
