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
