On binary host I have media-sound/timidity++ built, which some time ago depended on media-libs/alsa-lib[midi]. Now media-libs/alsa-lib has no midi USE flag and on binary host alsa-lib was rebuilt without midi USE. Now on systems using that binary host I see the following error: emerge: there are no ebuilds built with USE flags to satisfy "media-libs/alsa-lib[midi]". !!! One of the following packages is required to complete your request: - media-libs/alsa-lib-1.0.20-r1 (Missing IUSE: midi) - media-libs/alsa-lib-1.0.19 (Missing IUSE: midi) - media-libs/alsa-lib-1.0.17a (Missing IUSE: midi) - media-libs/alsa-lib-1.0.20-r1 (Missing IUSE: midi) - media-libs/alsa-lib-1.0.19 (Missing IUSE: midi) (dependency required by "media-sound/timidity++-2.13.2-r10" [binary]) (dependency required by "world" [argument]) Of course workaround is to rebuild timidity++ on binary host, but it'll be great if portage could handle such situations (probably rebuild if DEPEND atom changed).
I guess we could add something similar to --newuse, maybe called --new-deps.
BTW, I've just encountered similar issue but not with USE flag, but with dependencies: openoffice used perl-Compress-Zlib dependency and after that changed on IO-Compress. Still I had to reemerge openoffice just to update dependency in openoffice. BTW, may be we don't need to rebuild packages but just somehow update dependencies in xpack? Like package move or similar?
(In reply to comment #2) > BTW, may be we don't need to rebuild packages but just somehow update > dependencies in xpack? Like package move or similar? We already to something similar for installed packages on-the-fly. This behavior and the reason for it is described in bug #239006, comment #4. I suppose we could add an emaint task in order to perform this operation on binary and/or installed packages. In EAPI 3, the new SLOT operator dependencies (bug #273625) require that dependencies be locked to a specific SLOT value at build time (and saved in *DEPEND of the installed package). So, for these kinds of dependencies, the SLOTs recorded in the built/installed *DEPEND would have to be merged with the modified *DEPEND from the ebuild in the tree.
package renaming/slot changing is one thing, but i dont think you can safely screw with use deps. how is portage supposed to have any idea at all of what changed in the ebuild and what is safe to change the depend to ?
Well, lack of revbump could be taken to indicate that it's mostly safe to update *DEPEND without rebuild. However, rebuild is definitely the safest approach. There's a branch here that's supposed to implement that: http://github.com/few/fews-portage-branch/tree/reinstall-changed-ebuild
*** Bug 477116 has been marked as a duplicate of this bug. ***
Honestly I'm fine with forcing a rebuild no matter what if everyone else thinks it's safer. What isn't cool is the current "do nothing and fail". Let's just force a rebuild for now (it's better than failure) and see how it goes.
The @changed-deps set is available since portage-2.2.13: https://github.com/gentoo/portage/commit/3553e8bc274ae5b736a47ed8f1acc4bf472a7af4
(In reply to Zac Medico from comment #8) > The @changed-deps set is available since portage-2.2.13: > > https://github.com/gentoo/portage/commit/ > 3553e8bc274ae5b736a47ed8f1acc4bf472a7af4 The @changed-deps set is useful, but it has limitations similar to the @installed set (see bug #387059), which can make it unsuitable for use when updating the whole system. Therefore, it is desirable to implement two new options that are analogous to --newuse and --binpkg-respect-use, called --changed-deps and --binpkg-changed-deps. The rationale for having a separate --binpkg-* option is the same in both cases: depending on the situation, people may want different behavior for binary packages. For example, just like ---binpkg-respect-use is automatically enabled if the user has not specified --usepkgonly, the same can be done for --binpkg-changed-deps (though the user can explicitly override the automatic behavior). In both cases, inconsistencies in dependencies are automatically avoided, increasing the probability of a successful dependency calculation. In the following branch I have a patch implementing --changed-deps and --binpkg-changed-deps: https://github.com/zmedico/portage/tree/changed-deps I've posted it for review here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5030
This is in the master branch now: https://github.com/gentoo/portage/commit/e99fa094ac73514b23509a0f8305b365f114e9a3
Released in portage-2.2.16.
*** Bug 674886 has been marked as a duplicate of this bug. ***
