Summary: | sys-apps/portage-2.2.0_alpha45: --update --deep --newuse --noreplace propose downgrading of packages | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Cyprien Nicolas (fulax) <cyprien> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 373933 | ||
Attachments: |
emerge -p -DunN gd --debug &> debug1.log; bzip2 debug1.log
emerge -p -DuN gd --debug &> debug2.log; bzip2 |
Description
Cyprien Nicolas (fulax)
2011-07-18 15:28:24 UTC
(In reply to comment #0) > I noticed that combining --newuse and --noreplace (together with --update > --deep) makes portage try to find downgrades with different IUSE. > > The portage(1) manual, for --noreplace, says: "Also note that this option takes > precedence over options such as --newuse, preventing a package from being > reinstalled even though the corresponding USE flag settings may have changed." If a different version gets pulled in --noreplace and --newuse are irrelevant because the difference in version is an overriding factor. > So either the documentation is not correct, of the portage behavior is not. The documentation could be clarified to indicate that version changes are an overriding factor. > $ emerge -p -DunN gd > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild UD ] app-text/ghostscript-gpl-9.01 [9.02] USE="X cups gtk idn > -bindist -djvu -jpeg2k (-dbus%*)" LINGUAS="-ja -ko -zh_CN -zh_TW" 0 kB > > $ emerge -p -DuN gd > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > > Total: 0 packages, Size of downloads: 0 kb I don't understand why the ghostscript-gpl update was not pulled in by the second command. Please attach debug output for both commands: emerge -p -DunN gd --debug &> debug1.log emerge -p -DuN gd --debug &> debug2.log Created attachment 280319 [details]
emerge -p -DunN gd --debug &> debug1.log; bzip2 debug1.log
Created attachment 280321 [details]
emerge -p -DuN gd --debug &> debug2.log; bzip2
This seems to be a strange interaction between --noreplace and --newuse. Since you have ghostscript-gpl-9.02 installed, --noreplace causes the corresponding unbuilt ebuild of the same version to be rejected, and then ghostscript-gpl-9.01 gets pulled in to satisfy the dependency instead. I'm not sure if this is worth "fixing". Maybe we should simply deprecate the --noreplace option or make it an alias for --selective. The --selective option has a similar effect, but without the extra logic that makes --noreplace give strange results in this case. (In reply to comment #4) > I'm not sure if this is worth "fixing". Maybe we should simply deprecate the > --noreplace option or make it an alias for --selective. I suppose we could try to make --noreplace avoid downgrades, but it doesn't seem worth supporting. I'd rather just simplify things by removing the version-related logic and making --noreplace an alias for --selective. (In reply to comment #4) > This seems to be a strange interaction between --noreplace and --newuse. Since > you have ghostscript-gpl-9.02 installed, --noreplace causes the corresponding > unbuilt ebuild of the same version to be rejected, and then > ghostscript-gpl-9.01 gets pulled in to satisfy the dependency instead. --noreplace is supposed to only apply to packages given on the command-line, not dependencies. As you said that ghostscript-gpl-9.02 is skipped because of --noreplace, now I'm sure I hit a bug here. It happens also with --changed-use instead of --newuse. > I'm not sure if this is worth "fixing". Maybe we should simply deprecate the > --noreplace option or make it an alias for --selective. The --selective option > has a similar effect, but without the extra logic that makes --noreplace give > strange results in this case. Sounds safe, if this extra logic offers no benefits. Another possibility could be to keep the current logic of --noreplace into something like --reinstall=no, and make --noreplace as an alias for --selective, as you said. (In reply to comment #6) > --noreplace is supposed to only apply to packages given on the command-line, > not dependencies. If we only applied the logic for atoms given on the command-line, people will still be able to trigger strange behavior that's worthy of bug reports. I'd much rather remove the strange logic and be done with it. > Sounds safe, if this extra logic offers no benefits. > > Another possibility could be to keep the current logic of --noreplace into > something like --reinstall=no, and make --noreplace as an alias for > --selective, as you said. I don't want to rename it because that still leaves an avenue for future bug reports about the strange behavior. This makes --noreplace identical to --selective: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=72f83d8078da7aab7be9236b86be1526c15a4185 This is fixed in 2.1.10.7 and 2.2.0_alpha46. |