I recommended to a user in the #gentoo IRC channel that he use emerge -puvD arch, and was asked by a user what the -D is for. This spawned a conversation about when using -D is appropriate, and no one was able to argue that it does NOT make sense for emerge NOT to behave as if -D had been entered by default. Here is the conversation: <Devi0s> liquidbit: ACCEPT_KEYWORDS="~x86" emerge -pvD arch <Katana`> D ? <Katana`> what's the D flag for ? <Devi0s> the D flag is for: I don't know when to use --deep and when it is unecessary, so I pretty m uch just include it all of the time... <EagleTitan> Devi0s: the D flag is used to track dependancies that also need updates when running an emerge -u world <Devi0s> does that mean I only need to use D when doing emerge world or emerge system? <Sunflare> It depends. <Sunflare> Do you explicitly emerge every dependency? <Sunflare> i.e. Do you type 'emerge kde' or do you type 'emerge arts kdebase kdefoo kdebar kdebaz ...' <Devi0s> of course not <slarti`> Devi0s: remember that if libraries are upgraded or otherwise modified under programs that link to them, that program might break till it is recompiled <Devi0s> Sunflare: so it's safe to say I should probably include -D for everything like I have been doing... <slarti`> Devi0s: you will have to do a revdep-rebuild to check for and fix any problems like that <Sunflare> Devi0s: It certainly doesn't hurt. I use -D religiously, even though I /do/ emerge everything explicitly ('emerge arts kdebase ...'). <slarti`> Devi0s: .. a lot of the time, I think upgrading deeply is a bit of a waste of time * Devi0s still doesn't get it... isn't a large development goal for a package manager to make these decisions for you automatically? I still don't understand why the heck anyone would ever NOT use -D... <bus_drivr> Devi0s: if there are no "Depends" you would not need -D <Sunflare> Right. All those packages with no dependencies. <Sunflare> ;) <Devi0s> bus_drivr: but including it wouldn't change the behavior of portage in those cases, right? <bus_drivr> Devi0s: no <Sunflare> Devi0s: One way to look at it is that --deep catches updated libraries, which is typically A Good Thing. F'rex, if you use GNOME, it'll catch a revbump in gtk+, which (unless you emerged it explicitly) you'd otherwise miss. <Devi0s> Then I think it would make more sense to make -D happen by default, and have a switch to PREVENT that behavior... doesn't this lead to more noobs with healthier gentoo systems? <Sunflare> Devi0s: Perhaps. --deep didn't even exist until "recently," hence my habit of explicitly emerging every package and dependency to populate my world file. <Devi0s> Sunflare: sounds uneccesarily painful to me... <Sunflare> Devi0s: Old habits die hard. ;) Reproducible: Always Steps to Reproduce:
I think it should behave like this (--deep on) in ALL cases... :-) You never know how many steps it takes from the "world file" record to the package that is to be upgraded and if you didn't use the --deep you wouldn't even know about it... Radek
*** Bug 49142 has been marked as a duplicate of this bug. ***
Does anybody here really think, that my reported bug 49142 is a duplicate of this? I don't think so, since 'emerge -De world' does not change behaviour to 'emerge -e world' on my system. SpanKY, why do you think that?
I don't think that -D should be the default... 1. It takes longer to calculate, because it has to check everything installed 2. For the most part, people to not need to update every single little library 3. If they are a control freak, and want to, the will probably know about -D 4. If I emerge something, but don't want some dep it has that doesn't really need, then -D will want to re-emerge that dep, -u won't Then again, I could just be babbling, but I would definately do some more looking into it, before making -D the default behavior...
emerge -u world is for upgrading your world file. -D means look for and upgrade all the dependencies ( ie packages not in world, but still installed ). This is useful to have around especially if you are running a tight ship ( production server, who needs to update all the deps? Critical changes only ). As for the default...If you look at 'emerge -u world' emerge is doing exactly what it 'looks' like. It's updating everything in 'world'. It doesn't say anything about dependencies, and I don't think it should touch them automatically.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for consideration.
If we make --deep default then we'll also need to allow the user the control how greedy the update selection algorithm is. For example, perhaps the user wants to ensure that all dependencies are satisfied (which --deep does) but only wants to perform the minimal possible number of updates (--deep triggers the maximum possible number of updates). Bug #38674 is related.
*** Bug 162853 has been marked as a duplicate of this bug. ***
I dont think that forcing -D is a good idea. However, It would be nice to have a config file or environment variable where a user can specify that he wants to force -D.
(In reply to comment #10) > I dont think that forcing -D is a good idea. However, It would be nice to have > a config file or environment variable where a user can specify that he wants to > force -D. The can be done with EMERGE_DEFAULT_OPTS in make.conf. I don't want to make --deep default since then we'd need to add a --shallow option and that would probably just be confusing for users. In the future, I plan for the resolver to automatically ensure that deep dependencies are satisfied, but deep dependencies won't be upgraded unless the user specifically requests it via --deep.
Alternatively, we might add a special "upgrade" target that would be analogous to debian's "apt-get upgrade" command: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg46145.html
