Re: [gentoo-dev] Re: Build dependencies and upgrades.
On 10/12/2011 08:20 PM, Mike Frysinger wrote: On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` At this time, @installed tends to trigger unsolvable blockers during updates [1], so it's not really usable for general purpose updates unless you want users to go back to the days of solving blocker by themselves even though the package manager is capable of doing it automatically. Also, @installed pulls in slot atoms just for the installed slots, so it won't pull in new slots like un-slotted atoms would. [1] https://bugs.gentoo.org/show_bug.cgi?id=387059 -- Thanks, Zac
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Tue, Oct 11, 2011 at 7:27 PM, Duncan 1i5t5.dun...@cox.net wrote: That's probably why there's no mention in the docs other than the portage manpage. Now that we have swift back, he's applying some much needed attention to the docs tree and its coming back into shape. =:^) I definitely agree that the docs probably need a little improvement. Our docs should suggest to users the safest behavior for somebody who doesn't know what they're doing. That is, the behavior that leads to the fewest bug reports or list posts or general complaints. By all means give them less safe alternatives with some educational material (we empower our users). However, the first thing presented should be the safest default behavior. That leads me to another concern. The defaults should be the safe options, and the options should be to make the actions less safe. 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, and --without-bdeps be added (ok, those are lousy names but you get the picture). The default without any option should be to do the right thing for most people, and specifying an option should be to make the system do something less conservative. 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.) Rich
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On 10/12/2011 07:10 AM, Rich Freeman wrote: That leads me to another concern. The defaults should be the safe options, and the options should be to make the actions less safe. 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, and --without-bdeps be added (ok, those are lousy names but you get the picture). The default without any option should be to do the right thing for most people, and specifying an option should be to make the system do something less conservative. 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.) 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. -- Thanks, Zac
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, Oct 12, 2011 at 11:09 AM, Zac Medico zmed...@gentoo.org wrote: 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. I think this is a good idea - and I wasn't seriously proposing that we just change those flags (if we were to do it we'd have to deprecate them slowly/etc). Perhaps define that --upgrade means do the right thing (TM) and that it shouldn't be used in scripts unless those using the script are willing to tolerate that this behavior could change over time. Rich
[gentoo-dev] Re: Build dependencies and upgrades.
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
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, Oct 12, 2011 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` Well, you'd arguably at least need a -N in there. Also, this doesn't work in stable portage - I assume this is something available in the newer branch. In any case, if that is the right thing then we should update our docs accordingly. Also - will doing an emerge -u @installed add those packages to @world - ie do we need to throw a -1 in there, or is this behavior coded in as an exception? Rich
[gentoo-dev] Re: Build dependencies and upgrades.
Rich Freeman posted on Wed, 12 Oct 2011 23:26:28 -0400 as excerpted: On Wed, Oct 12, 2011 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote: isn't that already done with @installed ? `emerge --upgrade @installed` Well, you'd arguably at least need a -N in there. Indeed. Also, this doesn't work in stable portage - I assume this is something available in the newer branch. Yes. @ denotes a set. Stable portage doesn't have sets in general yet, altho it is setup to recognize the two special sets, @system and @world (which for those sets only, for backward compatibility, may appear with or without the @). In any case, if that is the right thing then we should update our docs accordingly. Of course, that would need to wait for sets to stabilize. When that might be I haven't the foggiest, but it'd be nice to not have to be running hard-masked portage, again. (FWIW, my world file is entirely empty as all the packages formerly contained therein are now in custom sets, @local.admin, @local.fonts, @local.kde.base.kdebase.workspace, @local.xorg, etc, and those are in turn listed in the world-sets file, not world, which is for packages, not sets.) Also - will doing an emerge -u @installed add those packages to @world - ie do we need to throw a -1 in there, or is this behavior coded in as an exception? Sets are recognized by the @ in front of them, and would normally be added to world-sets instead of world, but there's a number of special sets like @selected (@world minus packages only pulled in by @system) @system, @world, @installed, @live-rebuild (basically - versions), @preserved-rebuild, @security, @unavailable-binaries (AFAIK, @installed minus binpkg-available), @module-rebuild (external kernel modules), @x11- module-rebuild, etc. So yes, @installed is one of the special sets and therefore an exception. But... talking about -1 in context of --best (or whatever), I've always wondered why that wasn't the default, as well. Only add the package to @world if the user specifies to do so. That way a user can remerge an individual package (or set), without having to worry about whether it's going to be added to the world (world-sets) file, as it's only added when the option is specifically listed. But for that to work with --best, --best would have to be in EMERGE_DEFAULT_OPTIONS (with --best cancellable by later options if necessary), or people would be even MORE likely to forget to add the -1 for one-off emerges. -- 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
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Wed, 12 Oct 2011 23:20:23 -0400 Mike Frysinger vap...@gentoo.org wrote: On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` -mike Wouldn't that upgrade packages which are not needed by anything as well? I.e. those which will be removed on next depclean. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Thursday 13 October 2011 01:33:07 Michał Górny wrote: On Wed, 12 Oct 2011 23:20:23 -0400 Mike Frysinger wrote: On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: How about if we add a `emerge --upgrade` target that is analogous to `apt-get upgrade`? isn't that already done with @installed ? `emerge --upgrade @installed` Wouldn't that upgrade packages which are not needed by anything as well? I.e. those which will be removed on next depclean. pretty sure that's what the OP wanted -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Build dependencies and upgrades.
Mike Gilbert posted on Tue, 11 Oct 2011 17:04:02 -0400 as excerpted: On Tue, Oct 11, 2011 at 2:50 PM, Francisco Blas Izquierdo Riera (klondike) klond...@gentoo.org wrote: So, is there any reason for this behaviour? Shouldn't build dependencies either be cleaned with --depclean after building or be upgraded to avoid possible issues? I agree: with-bdeps should either default to y or n across the board. I understand the idea behind turning it on for depclean to reduce the amount uninstalls/re-installs, but I think that really just introduces more confusion than the time savings is worth. FWIW, --with-bdeps is a relatively new portage option. AFAIK it was added during the period when the docs team was pretty much just a single person, who was getting further and further behind and was understandably burnt out, but being the only person available, he remained at his post tho I'm sure he would have MUCH rather done something else. That's probably why there's no mention in the docs other than the portage manpage. Now that we have swift back, he's applying some much needed attention to the docs tree and its coming back into shape. =:^) So yes, I'd suggest a handbook update is in order. Well, either that, or arguably, a tweak of the portage defaults. But of course Zac's the guy who knows most about that, and why the defaults are what they are, so he's the one that needs to answer on that angle. Meanwhile, thanks for bringing it up, klondike. =:^) -- 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
