Re: [gentoo-user] portage getting mixed up with USE?

[Alan McKinnon]

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