[gentoo-dev] Re: Build dependencies and upgrades.

[Duncan]

Zac Medico posted on Wed, 12 Oct 2011 08:09:56 -0700 as excerpted:

> On 10/12/2011 07:10 AM, Rich Freeman wrote:
>> The defaults should be [safe] and the options should [flexibly
>> allow less safety where judged necessary].
>>
>> In my thinking the most conservative options right now are either
>> emerge -uDN world or emerge -uDN --with-bdeps=y world.
>>
>> I'd almost prefer to see that -D, -N, and --with-bdeps go away, and
>> that instead we add options like --shallow, --ignoreusechanges [...]

>> I just think about Debian where you tell people run "apt-get update"
>> and then "apt-get upgrade" and that is it.  Their typical behavior is
>> not specifying anything and you get everything updated.  With Gentoo
>> the equivalent is "emerge world" but when you do that you potentially
>> miss a lot of stuff.
>>
>> (And I realize the --with-bdeps part of this is debatable.)

I've privately thought similarly for quite some time, but rationalized 
it, as I expect many have, with the "gentoo isn't and never has been 
about babysitting" thing.  We expect, even essentially demand, that our 
users actively assertively their own choices in such matters by choosing 
the options that make sense for them, because otherwise, there's 
basically no point to running the distro.

But that doesn't mean we can't create a simple default that "just works" 
and is secure without all the arcane options.

> How about if we add a `emerge --upgrade` target that is analogous to
> `apt-get upgrade`? If we hide the new defaults behind a target like
> --upgrade, rather than change the defaults globally, then it allows
> people's existing scripted and habitual emerge commands to continue to
> work in a backward compatible manner.

This was exactly the point and suggestion that I expected Zac to make, 
and that I agree with just as strongly.  Don't break existing working 
assumptions and scripts with new defaults, but do take advantage of the 
opportunity presented by this discussion to create a single sensible 
option that "just works" and does so safely. =:^)

Meanwhile, Zac, if I may, another suggestion.  In the manpage and other 
documentation of this option, specifically note that the intended purpose 
is a single option that "just works", and that as such, specific behavior 
of the option may change as portage itself changes.  Thus, for scripts, 
etc, where unchanging specific behavior is intended, the individual 
specific options are recommended, instead.

That way, a half decade or whatever down the line, when portage's best 
defaults have again changed, we won't be faced with the problem of 
creating a new "best single default option" to avoid breaking existing 
assumptions, because the explicit assumption about this option is that it 
will always do what's considered best, even if that changes its behavior 
over time, and people have the option of picking either unchanging 
behavior with individual options, if that's desired, or a single option 
that's always intended to give the best behavior, even if that changes 
over time.

In that regard, perhaps call the option --best, or some such, so it can 
be used for upgrades, fetches, or whatever, and can be suggested for 
EMERGE_DEFAULT_OPTS, where --upgrade might not always be appropriate.

Also, make it possible to override what --best might otherwise do with 
later options.  So a command including --best --with-bdeps=n in that 
order would do what --best would do, except --with-bdeps=n would override 
it for that specific option.  (Conversely, --with-bdeps=n --best would 
ignore the bdeps option since best overrode it.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman