Currently, build-time dependencies are pulled in and installed without need. An ordinary `emerge -uD`, for example, will happen to install only build-time dependencies for packages which are already installed and not updated. --with-bdeps=n would make a better default in this case. This still touches the problem of how or whether portage distinguishes in such a situation, mainly between - Update an already-installed build-time dependency (to keep the system up-to-date) - Install a currently unnecessary build-time dependency where I suppose manual user intervention using --exclude or a specific atom as target will be required. This should revert bug 598444 which was introduced as a work-around for bug 592880, so that the dependency on the real problem can be tracked here. Reproducible: Always
Set EMERGE_DEFAULT_OPTS="--with-bdeps-auto=n" in /etc/portage/make.conf if you want to disable the automatic --with-bdeps behavior. Perhaps the biggest problem with having --with-bdeps disabled is that it can lead to a state where the dependencies of build-time dependencies are broken. The means that there are installed package that are non-functional, and it also means that emerge --depclean will abort as in bug 266861. It's not a sane default behavior.
(In reply to Zac Medico from comment #1) > Perhaps the biggest problem with having --with-bdeps disabled is that it can > lead to a state where the dependencies of build-time dependencies are > broken. Could you give an example for what you mean by that? Or is there perhaps even an according bug which this one could depend upon?
An example is this emerge --depclean error from bug 266861, comment 0: > Calculating dependencies... done! > * Dependencies could not be completely resolved due to > * the following required packages not being installed: > * > * >=virtual/perl-IO-Compress-Bzip2-2.012 pulled in by: > * perl-core/Archive-Tar-1.40 > * With --with-bdeps=n, the dependencies of build time dependencies are not guaranteed to be satisfied. Currently, the only solution to this problem is to use --with-bdeps=y, which guarantees that the dependencies of build time dependencies will be satisfied. It's not a bug, because --with-bdeps=n is intended to ignore build time dependencies.
Maybe --with-bdeps is meant to be less "porcellain" and more "plumbing" than it was my impression. From my user perspective, --with-bdeps=n has been a synonym for "only do actually relevant things", as in, things that will have (positive consequences for me). Which excludes things like "update packages which I will not use, because they are only build-time dependencies of up-to-date packages". I would like to know whether there has ever been any intention from the developers that --with-bdeps be used in that or at least a similar manner. If not, I will revoke my opinion on whatever --with-bdeps does or is supposed to do, because then I don't understand its purpose in the first place.
There was a time when --complete-graph mode would protect the dependencies of build time packages even with --with-bdeps=n, but that behavior was removed in this commit due to complaints that it was a waste of cpu time: https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6cb6af7cf6a443b892f32f1408a98c6bd4d3c10 We could add an option to re-enable the above behavior. However, --with-bdeps=n still is not a friendly default, since most people tend to want all of their packages at the latest versions, and the extra time that it takes to build the latest versions of those package is typically negligible in comparison to the time it takes to build all of the runtime packages. Common uses of --with-bdeps=n are: 1) In order to install binary packages from a build host, when the build time dependencies are not needed on the client (--usepkg implies --with-bdeps=n by default). 2) As a means to remove build-time dependencies from a system in order to save space, using emerge --depclean --with-bdeps=n.
(In reply to Zac Medico from comment #5) > 2) As a means to remove build-time dependencies from a system in order to > save space, using emerge --depclean --with-bdeps=n. And consequently, if I may add, to prevent them from being re-installed, as I meant to illustrate in my introductory example. Not to cycle back there, but is it understood that `--with-bdeps` would cause the problems you mentioned (for which I would need some more time to fully grasp them), even if it were made the default *for only* the mentioned `-uD` operation (again, as you said, to prevent the depcleaned bdeps to be re-installed)?
