| Summary: | sys-apps/portage doesn't show all possible updates unless --with-bdeps=y is specified | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mark Nowiasz <mark+gentoobugs> |
| Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | ansla80, anton.bugs, de.techno, dieter.ferdinand, esigra, itumaykin+gentoo, mjo, SebastianLuther, solstag, steffen, wolf31o2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=598444 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mark Nowiasz
2009-06-17 06:36:25 UTC
Is x11-base/xorg-server in your world file or some set listed in world_sets? If not, emerge --noreplace x11-base/xorg-server should fix it. sys-apps/portage-2.1.6.13 also shows this behaviour - after downgrading to 2.1.6.13, emerge -up --deep world system also shows the same symptoms. (In reply to comment #1) > Is x11-base/xorg-server in your world file or some set listed in world_sets? If > not, emerge --noreplace x11-base/xorg-server should fix it. Well, to my understanding --deep should take care of packages not listed in world or world_sets? Anyway, this isn't really a solution, because there are a couple of more packages not shown which have got updates: yesterday I updated my local machine (it did show some X11 related updates, I've forgotten which, maybe something with render?). *This* machine doesn't show these updates at all (neither portage 2.2 nor 2.1). So right now I cannot trust portage on this machine to show me all updates - and relying on writing down all updates shown on another machine and emerging them manually can't be a solution, either. Another package which doesn't show in the updates here: virtual/perl-IO-Compress-Bzip2-2.020 After trying to figure out if a depclean might help, I've encountered * Dependencies could not be completely resolved due to * the following required packages not being installed: * * >=virtual/perl-IO-Compress-Bzip2-2.015 pulled in by: * perl-core/Archive-Tar-1.48 emerge --update --newuse --deep @system @world didn't show the package, either - so a emerge -p =perl-core/Archive-Tar-1.48 would result in [ebuild N ] virtual/perl-IO-Compress-Bzip2-2.020 [ebuild R ] perl-core/Archive-Tar-1.48 (In reply to comment #3) > (In reply to comment #1) > > Is x11-base/xorg-server in your world file or some set listed in world_sets? If > > not, emerge --noreplace x11-base/xorg-server should fix it. > > Well, to my understanding --deep should take care of packages not listed in > world or world_sets? No, what --deep does is to consider the complete dependency graph. If some package isn't in there, it's not going to see updates for it. (see man emerge) > > Anyway, this isn't really a solution, because there are a couple of more > packages not shown which have got updates: yesterday I updated my local machine emerge -pD xorg-server should show them. So right now I cannot trust portage on this machine to > show me all updates - and relying on writing down all updates shown on another > machine and emerging them manually can't be a solution, either. That's not a problem with portage, but with your configuration. emerge -uDN @installed should include xorg-server in your case. (In reply to comment #4) > Another package which doesn't show in the updates here: > > virtual/perl-IO-Compress-Bzip2-2.020 > > After trying to figure out if a depclean might help, I've encountered > > * Dependencies could not be completely resolved due to > * the following required packages not being installed: > * > * >=virtual/perl-IO-Compress-Bzip2-2.015 pulled in by: > * perl-core/Archive-Tar-1.48 > > emerge --update --newuse --deep @system @world didn't show the package, either > - so a > Add --with-bdeps=y. (In reply to comment #5) > > Well, to my understanding --deep should take care of packages not listed in > > world or world_sets? > > No, what --deep does is to consider the complete dependency graph. If some > package isn't in there, it's not going to see updates for it. (see man emerge) Alright, but since KDE (which is installed here) plus a ton of other X apps are depending on xorg-server, --deep should consider xorg-server, shouldn't it? Well, emerge -uDN @installed does work, indeed. I still find it strange that - although there are a lots of packages depending on xorg - xorg won't be found when using --deep @world @system. Oh well. Did you try emerge -uDpNv --with-bdeps=y @world as Sebastian suggested? (In reply to comment #6) > (In reply to comment #5) > Alright, but since KDE (which is installed here) plus a ton of other X apps are > depending on xorg-server, --deep should consider xorg-server, shouldn't it? What gives "equery d xorg-server"? And your emerge --info please. (In reply to comment #8) > What gives "equery d xorg-server"? And your emerge --info please. > crusoe ~ # equery d xorg-server * Searching for xorg-server ... dev-python/pygobject-2.16.1-r1 (X ? x11-base/xorg-server) dev-python/pygtk-2.14.1 (X ? x11-base/xorg-server) gnome-base/libgnomecanvas-2.26.0 (X ? x11-base/xorg-server) media-video/nvidia-settings-180.60 (x11-base/xorg-server) x11-drivers/nvidia-drivers-180.60 (<x11-base/xorg-server-1.6.99) x11-drivers/xf86-input-evdev-2.2.1 (>=x11-base/xorg-server-1.5.3) x11-drivers/xf86-input-keyboard-1.3.2 (>=x11-base/xorg-server-1.3.99) x11-drivers/xf86-input-mouse-1.4.0 (>=x11-base/xorg-server-1.0.99) x11-libs/gtk+-2.16.1 (X ? x11-base/xorg-server) Odd... because (for example) crusoe ~ # grep kde /var/lib/portage/world kde-base/kde-meta kde-misc/konq-plugins sci-calculators/qalculate-kde crusoe ~ # emerge --info Portage 2.2_rc33 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.10.1-r0, 2.6.30-gentoo-r1 x86_64) ================================================================= System uname: Linux-2.6.30-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E4500_@_2.20GHz-with-gentoo-2.0.1 Timestamp of tree: Thu, 18 Jun 2009 05:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p24 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.5.4-r3, 2.6.2-r1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.29 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.mneisen.org/ http://de-mirror.org/distro/gentoo/ ftp://de-mirror.org/distro/gentoo/ http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://mirror.jamit.de/gentoo/ http://mirror.netcologne.de/gentoo/ ftp://mirror.netcologne.de/gentoo/ " LANG="de_DE.utf8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X XFACE a52 aac aalib acl acpi aim alsa amd64 ao apache2 audiofile bash-completion bcmath blas bluetooth branding bsf bzip2 cairo calendar cddb cdparanoia cdr cli consolekit cracklib crypt cscope css ctype cups curl cxx dbus derby djvu dri dts dv dvb dvd dvdr dvdread encode enscript exif expat fam ffmpeg fftw firefox flac fontconfig foomaticdb fortran ftp gd gdbm geoip gif gimp git glut gmp gnuplot gnutls gpg gphoto2 gpm gps graphviz gsl gtk gzip hal htmlhandbook iconv icq icu idn imagemagick imap imlib innodb ipv6 isdnlog jabber java java6 javascript jbig jingle jpeg jpeg2k kde kontact lame lapack lash latex lcms ldap libcaca libedit libnotify libsamplerate libwww lua lzo mad maildir mailwrapper matroska mhash midi mikmod mime mmap mmx mng modplug mp3 mpeg mpi mplayer msn mudflap multilib musepack musicbrainz mysql mysqli ncurses netcdf nls nntp nptl nptlonly nsplugin offensive ofx ogg openal openexr opengl openmp openssl osc oscar pam pcntl pcre pda pdf perl php plasma plotutils png policykit portaudio posix postgres ppd pppd python qt3 qt4 quicktime raw rdesktop readline reflection rss samba sasl scanner sdl session sharedext sharedmem shorten simplexml slang slp smp sndfile snmp soap sockets sox speex spell spl sse sse2 sse3 ssl startup-notification subversion suid svg sysfs syslog sysvipc szip taglib tcpd theora threads tidy tiff timidity tokenizer truetype unicode usb vcd videos vim-syntax vnc vorbis wavpack webkit wlm wmf x264 xattr xft xine xml xmlreader xmlrpc xmlwriter xorg xosd xpm xscreensaver xsl xulrunner xv xvid yahoo yaz zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Please attach --pretend --debug output for the command which does not pull in the expected update(s). (In reply to comment #6) > Alright, but since KDE (which is installed here) plus a ton of other X apps > are depending on xorg-server, --deep should consider xorg-server, shouldn't > it? > Well, emerge -uDN @installed does work, indeed. I still find it strange that > - although there are a lots of packages depending on xorg - xorg won't be > found when using --deep @world @system. Oh well. KDE and the rest of X apps only depend on the X libraries, not the X server, that was a design desicion to allow installing X apps on a headless server that will display their output on remote X clients so you will need to add xorg-server to the world file if you want it installed. The same here with sys-apps/portage-2.2_rc46 (today's sync): bash# emerge -DNupv world Calculating dependencies ... done! [ebuild U ] app-text/iso-codes-3.10 [3.8] 5,226 kB However: emerge -aepv world | grep "U ]" [ebuild U ] dev-perl/Locale-gettext-1.05-r1 [1.05] 0 kB [0] [ebuild U ] app-text/iso-codes-3.10 [3.8] 5,226 kB [0] [ebuild U ] dev-util/cmake-2.6.4-r3 [2.6.4] USE="qt4 -emacs -vim-syntax" 0 kB [0] [ebuild U ] dev-cpp/eigen-2.0.9 [2.0.6] USE="-debug -doc -examples" 354 kB [0] Do you really need my "-e --debug" output? It's huge. (In reply to comment #7) > Did you try > > emerge -uDpNv --with-bdeps=y @world Oh, missed that one. Yes, that works. Shouldn't it be by default with -D?.. These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild U ] dev-perl/Locale-gettext-1.05-r1 [1.05] 0 kB [ebuild R ] dev-lang/swig-1.3.36 USE="java* perl python -R -chicken -clisp -doc -guile -lua -mono -mzscheme -ocaml -octave -php -pike -ruby -tcl -tk" 0 kB [ebuild U ] app-text/iso-codes-3.10 [3.8] 5,226 kB [ebuild U ] dev-util/cmake-2.6.4-r3 [2.6.4] USE="qt4 -emacs -vim-syntax" 0 kB [ebuild U ] dev-cpp/eigen-2.0.9 [2.0.6] USE="-debug -doc -examples" 354 kB Total: 5 packages (4 upgrades, 1 reinstall), Size of downloads: 5,580 kB (In reply to comment #13) > Oh, missed that one. Yes, that works. Shouldn't it be by default with -D?.. Mixing options together like that gets messy. Most people (but not everyone) can be perfectly happy by setting EMERGE_DEFAULT_OPTS="--with-bdeps=y" in /etc/make.conf. (In reply to comment #14) > (In reply to comment #13) > > Oh, missed that one. Yes, that works. Shouldn't it be by default with -D?.. > > Mixing options together like that gets messy. Most people (but not everyone) > can be perfectly happy by setting EMERGE_DEFAULT_OPTS="--with-bdeps=y" in > /etc/make.conf. > So should we set this? -A (In reply to comment #15) > > Mixing options together like that gets messy. Most people (but not everyone) > > can be perfectly happy by setting EMERGE_DEFAULT_OPTS="--with-bdeps=y" in > > /etc/make.conf. > > > > So should we set this? I guess we can set it in make.globals, and anyone who doesn't like it can override it in make.conf. (In reply to comment #16) > (In reply to comment #15) > > > Mixing options together like that gets messy. Most people (but not everyone) > > > can be perfectly happy by setting EMERGE_DEFAULT_OPTS="--with-bdeps=y" in > > > /etc/make.conf. > > > > > > > So should we set this? > > I guess we can set it in make.globals, and anyone who doesn't like it can > override it in make.conf. > Why would anyone want updates for things that aren't in use? Those packages are only used at build time of the reverse dependencies. So it makes only sense to update them if you want to rebuild the reverse dependency. (In reply to comment #17) > Why would anyone want updates for things that aren't in use? Those packages are because of security updates or any other critical fixes like it was with sys-apps/ed editor. IMHO, such "lost" packages has to be either up to date or removed from the system. (In reply to comment #18) > (In reply to comment #17) > > Why would anyone want updates for things that aren't in use? Those packages are > > because of security updates or any other critical fixes like it was with > sys-apps/ed editor. Why would an security update or an critical fix be relevant for things the user doesn't run? If you use it, put it in your world file. If some package uses it at runtime, it needs to depend on it. > IMHO, such "lost" packages has to be either up to date or removed from the > system. You could run "emerge --depclean --with-bdeps=n" after updating world. (In reply to comment #19) > Why would an security update or an critical fix be relevant for things the user > doesn't run? If you use it, put it in your world file. If some package uses it > at runtime, it needs to depend on it. Here is an example out of my head. Let's say there is a vulnerability in cmake which allows you to predict a location of temporary file. So an attacker create a special crafted file in place and wait for you to run system upgrade (emerge) which would run cmake with root privileges. That's why I think it has to be fixed by default and not as an option for a user. (In reply to comment #20) > (In reply to comment #19) > > Why would an security update or an critical fix be relevant for things the user > > doesn't run? If you use it, put it in your world file. If some package uses it > > at runtime, it needs to depend on it. > > Here is an example out of my head. Let's say there is a vulnerability in cmake > which allows you to predict a location of temporary file. So an attacker create > a special crafted file in place and wait for you to run system upgrade (emerge) > which would run cmake with root privileges. If emerge would update a package that uses cmake, cmake would be updated first. And since cmake doesn't use cmake itself, there wouldn't be a problem. (In reply to comment #21) > If emerge would update a package that uses cmake, cmake would be updated first. This bug report says it won't get updated. Here is the same case with dev-lang/nasm which I can see with the latest sync: ----------- emerge -DNupv --with-bdeps=y syslinux These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-lang/nasm-2.07 [2.05.01] USE="-doc" 762 kB [ebuild U ] x11-proto/bigreqsproto-1.1.0 [1.0.2] 48 kB [ebuild U ] x11-proto/xf86bigfontproto-1.2.0 [1.1.2] 49 kB [ebuild U ] x11-proto/xcmiscproto-1.2.0 [1.1.2] 48 kB [ebuild U ] dev-perl/Locale-gettext-1.05-r1 [1.05] 0 kB ---------- emerge -DNupv syslinux These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB ---------- Actually, I'm wrong. I does get updated in case of nasm (as DEPEND): -------- emerge -Dpv1 syslinux [ebuild U ] dev-lang/nasm-2.07 [2.05.01] USE="-doc" 762 kB [ebuild R ] sys-boot/syslinux-3.71 0 kB -------- emerge -DNupv world [ebuild U ] dev-lang/nasm-2.07 [2.05.01] USE="-doc" 762 kB [ebuild N ] sys-boot/syslinux-3.71 0 kB *** Bug 302335 has been marked as a duplicate of this bug. *** (In reply to comment #21) > If emerge would update a package that uses cmake, cmake would be updated > first. And since cmake doesn't use cmake itself, there wouldn't be a problem. Hi there! I was able to come up with one situation where this is still a problem, which revealed a more general issue. Consider that I ask emerge to install a new package which has a build time dependency, already installed in the system and outdated. This new package will get compiled using such outdated build time dependency, and the outdated code will be used, as Anton expected. This happens because, currently, build time dependencies get updated through the usual "emerge --update --deep --newuse @world" update procedure when there is an update to a package that bdeps on it, but not when a package that bdeps on it is emerged without "--update --deep". Such behavior of emerge breaks the concept that keeping your system up-to-date (with "emerge -uDNavt world") is enough to make sure packages you emerge are "as up to date as possible at the time they were compiled". I don't think this "concept" is explicit anywhere in the Gentoo docs, but it makes a lot of sense to me and I think that it represents what both users and developers would expect. Besides, this sounds like a realistic concern that could be addressed by default, unlike the proposal to keep all bdependencies always up to date. I have thought about this for a while (a couple of hours), and essentially became convinced that the best solution is the following. Whenever a package gets emerged - be it by command or pulled in; be it installed, reinstalled or updated - an update of its bdeps should be required. A new flag, "--update-bdeps=[y|n]", would let you skip this step. The rationale being that a package emerged in an up-to-date system should be as up to date as possible at the moment of its emerging. Where by up-to-date we mean updated by the usual procedure "emerge --update --deep --newuse @world". Another way to look at this is that, as we do not consider outdated bdeps when defining an "up-to-date system", we must account for them when emerging packages. Otherwise, packages may get emerged with ancient bdeps just because some other never-again-updated package pulled that bdep in a long time ago. And I don't think we want that happening by default. []'s ale .:. (In reply to comment #25) > Whenever a package gets emerged - be it by command or pulled in; be it > installed, reinstalled or updated - an update of its bdeps should be required. > > A new flag, "--update-bdeps=[y|n]", would let you skip this step. It seems like this behavior would be equivalent to --update --deep=1, which would cause direct dependencies to be updated to the latest available versions. (In reply to comment #26) > (In reply to comment #25) > > Whenever a package gets emerged - be it by command or pulled in; be it > > installed, reinstalled or updated - an update of its bdeps should be required. > > > > A new flag, "--update-bdeps=[y|n]", would let you skip this step. > > It seems like this behavior would be equivalent to --update --deep=1, which > would cause direct dependencies to be updated to the latest available versions. Hm.. not exactly, since that would include run time dependencies as well. And, more seriously, I think that would not include outdated build time dependencies of packages pulled in by those specified in the emerge command. (In reply to comment #27) > Hm.. not exactly, since that would include run time dependencies as well. Well, I doubt that many people would want to micro-manage the update behavior to this degree. They can always use the --exclude option or package.mask if they really need to prevent updates of some specific runtime dependencies. > And, > more seriously, I think that would not include outdated build time dependencies > of packages pulled in by those specified in the emerge command. If you want it to go as deep as possible, use --update --deep and that will make it pull in dependencies recursively. (In reply to comment #28) > Well, I doubt that many people would want to micro-manage the update behavior > to this degree. They can always use the --exclude option or package.mask if > they really need to prevent updates of some specific runtime dependencies. Hmm. I still think that since I'm talking about default behavior, it is worth the effort to make it do everything that is expected, but no more than that. > If you want it to go as deep as possible, use --update --deep and that will > make it pull in dependencies recursively. My point was that one shouldn't need to "--update --deep" (or "--update --deep=1" for that matter) only to get installing a package in an up-to-date system to be as up-to-date as possible. To be crystal clear, I'm saying that: emerge --update --deep --newuse @world emerge $package Should guarantee that $package has been emerged in the most up-to-date state possible, which includes using up-to-date build time dependencies for it and any packages being emerged indirectly. No problem if anyone disagrees with that, just want to make sure I'm being understood. []'s ale (In reply to comment #29) > My point was that one shouldn't need to "--update --deep" (or "--update > --deep=1" for that matter) only to get installing a package in an up-to-date > system to be as up-to-date as possible. > > To be crystal clear, I'm saying that: > > emerge --update --deep --newuse @world > emerge $package > > Should guarantee that $package has been emerged in the most up-to-date state > possible, which includes using up-to-date build time dependencies for it and > any packages being emerged indirectly. I agree that this would be a good property to have. However, I don't see a clean way to do it that doesn't conflict with the following two goals: 1) Keep --with-bdeps disabled by default, since it causes useless updates in some cases and also has implications for users of binary packages who don't expect build-time deps to be pulled in by default. 2) Do not enable --deep by default, since it makes dependency calculations slower and typically --deep is only useful for a minority of dependency calculations. > No problem if anyone disagrees with that, just want to make sure I'm being > understood. Well, given the conflicting goals mentioned above, I think the best solution is for people like you to set EMERGE_DEFAULT_OPTS="--with-bdeps=y" in make.conf. That's what I do on all of my systems, since I enjoy having the guarantee that all build time deps are always up to date. *** Bug 326871 has been marked as a duplicate of this bug. *** *** Bug 402977 has been marked as a duplicate of this bug. *** I think the root of the confusion is that people expect "@world" to mean "everything", when in reality it means something like "everything that you installed and its runtime dependencies." Maybe "emerge -uDN @everything" would be a nice user interface for the former. No, it's not any simpler than "emerge -uDN --with-bdeps @world", but it does get the point across a little better. (In reply to Michael Orlitzky from comment #33) > I think the root of the confusion is that people expect "@world" to mean > "everything", when in reality it means something like "everything that you > installed and its runtime dependencies." The current plan is to enable --with-bdeps automatically when possible, as described bug 598444, comment #4. > Maybe "emerge -uDN @everything" would be a nice user interface for the > former. No, it's not any simpler than "emerge -uDN --with-bdeps @world", but > it does get the point across a little better. Package sets are currently used to represent the roots of the dependency graph, while --with-bdeps modifies the handling of dependencies for packages that get pulled into the graph. Conceptually, they are very different things, so I would prefer not to have package sets that magically trigger --with-bdeps behavior. (In reply to Zac Medico from comment #34) > > The current plan is to enable --with-bdeps automatically when possible, as > described bug 598444, comment #4. That's a better solution if it's feasible. It's more consistent with the behavior of --depclean, which keeps the build dependencies around in first place. *thumbs up* > Package sets are currently used to represent the roots of the dependency > graph, while --with-bdeps modifies the handling of dependencies for packages > that get pulled into the graph. Conceptually, they are very different > things, so I would prefer not to have package sets that magically trigger > --with-bdeps behavior. Understood. |
