Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 282927 - binary packages miss USE flag chages (add an option to rebuild binary packages if DEPEND chages)
Summary: binary packages miss USE flag chages (add an option to rebuild binary package...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
Keywords: InVCS
: 477116 (view as bug list)
Depends on:
Blocks: 155723 332001 368725 484436
  Show dependency tree
Reported: 2009-08-27 16:28 UTC by Peter Volkov (RETIRED)
Modified: 2019-01-08 19:26 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Volkov (RETIRED) gentoo-dev 2009-08-27 16:28:29 UTC
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).
Comment 1 Zac Medico gentoo-dev 2009-08-28 07:42:31 UTC
I guess we could add something similar to --newuse, maybe called --new-deps.
Comment 2 Peter Volkov (RETIRED) gentoo-dev 2009-08-28 09:12:21 UTC
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?
Comment 3 Zac Medico gentoo-dev 2009-08-28 09:35:36 UTC
(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.
Comment 4 SpanKY gentoo-dev 2010-08-10 20:46:39 UTC
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 ?
Comment 5 Zac Medico gentoo-dev 2010-08-11 01:01:50 UTC
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:
Comment 6 Zac Medico gentoo-dev 2013-07-17 17:33:52 UTC
*** Bug 477116 has been marked as a duplicate of this bug. ***
Comment 7 Rick Farina (Zero_Chaos) gentoo-dev 2013-07-17 20:30:57 UTC
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.
Comment 8 Zac Medico gentoo-dev 2014-09-21 20:25:53 UTC
The @changed-deps set is available since portage-2.2.13:
Comment 9 Zac Medico gentoo-dev 2014-12-23 20:48:24 UTC
(In reply to Zac Medico from comment #8)
> The @changed-deps set is available since portage-2.2.13:
> 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:

I've posted it for review here:
Comment 10 Zac Medico gentoo-dev 2015-01-15 01:06:08 UTC
This is in the master branch now:
Comment 11 Brian Dolbec gentoo-dev 2015-02-15 00:52:18 UTC
Released in portage-2.2.16.
Comment 12 Zac Medico gentoo-dev 2019-01-08 19:26:34 UTC
*** Bug 674886 has been marked as a duplicate of this bug. ***