Hi, I notice that upgrade guides for multiple-package upgrades such as Gnome and modular X, do not mention using the -D/--deep option with the emerge command. This, I think, has been the cause of many failed compilations. A good example is the forum page below, in which the compilation of libXxf86misc fails because Portage ignores the dependency on libX11, which is one level further down, since -D was not specified. Proposed solution: Replace all non-trivial occurences of "emerge" (i.e. other than when the ebuilds have simple and shallow dependencies) in the documentation with "emerge -D" :) References: http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://forums.gentoo.org/viewtopic-t-439969-start-50.html
Wrong component. Please use "Doc other" for documents not found in /doc/ on gentoo.org; the guides in question are maintained by their individual projects.
CCing the respective authors of the documents so they can provide feedback, etc.
It's been my impression that --deep was being added to the default emerge options so that all emerges would be done with it.
although i'd like to say to always use -D, sometimes with gnome it causes upgrade / downgrade cycles. ( although i can't think of any packages with the issue right now )
I've just had an upgrade/downgrade conflict with poppler. It's fixed by setting up the package.* files to remove the ambiguity. I'd love to see the "deep" emerge option become the default, with a new "nodeep" option to use the old behaviour :)
Please update the documentation to include the -D option. My bug #135261 has been rejected.
(In reply to comment #4) > although i'd like to say to always use -D, sometimes with gnome it causes > upgrade / downgrade cycles. When this happens with stable packages, it's a bug. In testing it's up to the user to take care.
(In reply to comment #6) >My bug #135261 has been rejected. This is irrelevant to this particular bug. > Please update the documentation to include the -D option. Again, that's up to the individual authors of the docs. (In reply to comment #6) Until Portage-2.1 is marked stable (since that's the version that might make 0D default), it might be a good idea to change it to -D for the mod x guide. (In reply to comment #4) It's your call. Ping me on IRC if you'd rather have someone else modify your doc. :)
Sorry, correction: The command should be e.g. "emerge -DuN gnome" - "deep" seems to be useless without "update", and "newuse" should be brought to the attention of newbies struggling with the expert-mode parameters of emerge, otherwise they may think they've done a "proper" upgrade when in fact changed USE-flag functionality will not have been compiled-in.
Not a docs-team bug. Can't assign to both John & Donnie. John, you won the toss :)
Another example, if anyone's unconvinced: http://forums.gentoo.org/viewtopic.php?p=3390573#3390573
(In reply to comment #0) > I notice that upgrade guides for multiple-package upgrades such as Gnome and > modular X, do not mention using the -D/--deep option with the emerge command. > This, I think, has been the cause of many failed compilations. A good example > is the forum page below, in which the compilation of libXxf86misc fails because > Portage ignores the dependency on libX11, which is one level further down, > since -D was not specified. No. --deep should never be necessary. If some ebuild fails, because of some wrong minimum version listed as dependency, the ebuild is broken and you should file a bug for that.
(In reply to comment #12) > No. --deep should never be necessary. If some ebuild fails, because of some > wrong minimum version listed as dependency, the ebuild is broken and you should > file a bug for that. Absolute garbage. Kindly engage your brain.
(In reply to comment #13) > Absolute garbage. Kindly engage your brain. It's not. Otherwise the --deep option wouldn't exist and --update would do that what --update --deep does. Please apply your barefaced comment to yourself.
Nonsense. > No. --deep should never be necessary. Well, it is. Welcome to reality. Because ebuilds don't specify every single package as a dependency. They assume that the dependencies one level deep will be automatically satisfied. Which is correct behaviour. It it "emerge gnome", rather than "emerge -DuNe gnome", which is broken.
(In reply to comment #15) > Because ebuilds don't specify every single package as a dependency. If they don't, they're broken and you should file a bug. That simple. The whole point of the distinction between --update and --deep --update is to distinct between updating to what is necessary and to latest stable. Please grasp that.
(In reply to comment #16) > If they don't, they're broken and you should file a bug. I'm referring to dependencies which are *more* than 1 level deep. Such dependencies are not checked without --deep. Which requires --update. Yes, --deep may do more than some users want. That's a deficiency in Portage, rather than the ebuilds. So, given the emerge choices which are available, surely it's better to err on the side of *caution*, rather than run the risk of "emerge gnome" failing halfway-through (and thus leaving Gnome in an unuseable state) because Portage hasn't checked all the relevant dependencies. Compilation errors are a *bug*, yes? "-DuN" will prevent such bugs. "emerge gnome" simply does not check enough package dependencies, without those additional command-line options.
(In reply to comment #17) > I'm referring to dependencies which are *more* than 1 level deep. Such > dependencies are not checked without --deep. Which requires --update. O.k., let's construct an example: foo depends on bar and baz, but only bar is listed as dependency, since bar depends itself on baz. Know we have a new version foo that needs a different minimal dependency of baz than bar does. If the compilation fails for that reason, its the maintainer's fault, since he should have added e.g. >=baz-x.y as dependency to the new bar ebuild. > Compilation errors are a *bug*, yes? "-DuN" will prevent such bugs. The first yes, the second is a workaround, but doesn't fix the real problem. If the compilation fails on a plain emerge --update, because of dependency issues, it's either a bug in the ebuild or something Portage can't deal with yet (e.g. cyclic dependencies). The latter case -DuN can't fix either, for the former one it is a workaround, but the invalid depend atoms remain, which is a bigger problem. And there are a lot of ebuilds with insufficient dependencies in the tree.
(In reply to comment #18) That's an interesting dependency situation, and I agree that in that situation, the versioned dependency on the 3rd-level package should be specified in the 1st-level package's ebuild, because it's not satisfied by the 2nd-level package's dependencies. However, this does not mean that all ebuilds should start explicitly versioning every package in their entire dependency trees, because that would be overkill. This current bug is not concerned with Portage's handling of circular dependencies (sounds like an impossible problem anyway), or Portage's strong desire for the current version (caused by --update) which can end up being a convenient workaround for subtle versioning bugs in ebuilds. This bug is concerned with whether official (I updated the *unofficial* wiki entries months ago) Gentoo documentation should give users the *best* advice when upgrading e.g. Gnome, where "--deep" makes a big difference to the dependencies that Portage actually considers (rather than ignoring). Having potentially bad multi-layered dependencies in ebuilds is a reason *for* advocating -DuN, especially when bugs on bugzilla can be closed if the user is not using the *current* version of a package. Also, another relevant issue of dependencies is that we *cannot* assume that the installation is entirely up-to-date and clean, i.e. that "emerge -DuN world" does nothing. In the situation where some of the 3rd layer (or lower) packages are not sufficient for the Gnome version being emerged, they will *not* be checked without "--deep", which is a bug. This bug can be solved with either "-DuN" (as I keep recommending) or by adding all of the packages from "emerge -pe gnome" to the gnome ebuild (and all the other "major" emerges such as other desktop environments). Major emerges such as Gnome will be the most annoying places to come across ebuild dependency bugs, because no-one is going to watch the compilations whizz by for hours on end, waiting for one or more failures to have to rectify before the user can start the GUI again. They will be left overnight to run. So the emphasis should be on a *reliable* emerge, hence "-DuN".
(In reply to comment #19) > Having potentially bad multi-layered dependencies in ebuilds is a reason *for* > advocating -DuN, especially when bugs on bugzilla can be closed if the user is > not using the *current* version of a package. No. It's a reason to actually get the ebuilds fixed. You're trying to cure the symptom and propose to hide bugs. > Also, another relevant issue of dependencies is that we *cannot* assume that > the installation is entirely up-to-date and clean, i.e. that "emerge -DuN > world" does nothing. In the situation where some of the 3rd layer (or lower) > packages are not sufficient for the Gnome version being emerged, they will > *not* be checked without "--deep", which is a bug. Of course no developer can't expect that. That's why he has to make sure the dependencies within ebuilds are exact. The bug would be that the Gnome packages do not specify the needed dependencies in such a case. And caring for exact, deterministic dependencies is crucial, because otherwise we'll never see proper reverse dependency support, based on the ebuild information. > This bug can be solved with > either "-DuN" (as I keep recommending) or by adding all of the packages from > "emerge -pe gnome" to the gnome ebuild (and all the other "major" emerges such > as other desktop environments). No. The bug wouldn't be solved, as the relevant ebuilds won't be fixed. > Major emerges such as Gnome will be the most annoying places to come across > ebuild dependency bugs, because no-one is going to watch the compilations whizz > by for hours on end, waiting for one or more failures to have to rectify before > the user can start the GUI again. They will be left overnight to run. So the > emphasis should be on a *reliable* emerge, hence "-DuN". Sorry, that's crap. Please file a bug, when a simple emerge -u doesn't work, because of incorrect dependencies.
s/developer can't/developer can
Here's a simple script to run, to prove my point: http://forums.gentoo.org/viewtopic-p-3633731.html#3633731 It shows that the problem is solved by giving Portage the command-line options for it to check all deps and do its job properly.
http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml is fixed (Code Listing 4.2), don't see how the modular X thing is relevant here, so closing this bug.
This bug is not fixed, because the wrong code listing has been changed. The code listing that should be changed is the code listing that *emerges* gnome (which is precisely where it's most likely to fail), which is code listing 2.1 ("emerge -av gnome") at: http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.12-upgrade.xml
I'm sorry, but I completely fail to see why I should fix the upgrade guide for a verison of gnome not even in the tree anymore.
