Bug 147153 – --usepkgonly ignores --noreplace

• Product: Portage Development
• Status: RESOLVED INVALID

[Description Åsmund Grammeltvedt 2006-09-11 02:38:38 UTC]

Scenario 1:

$ emerge --noreplace openssh
Calculating dependencies... done!
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.


 * GNU info directory index is up-to-date.

---
Scenario 2:

$ emerge --noreplace --usepkgonly openssh
Calculating dependencies   
!!! There are no packages available to satisfy: "openssh"
!!! Either add a suitable binary package or compile from an ebuild.

Is this the intended behaviour? This causes problems if we only have built binaries for those packages that should be upgraded.

[Comment 1 Jason Stubbs (RETIRED) 2006-09-11 05:30:35 UTC]

It is correct. --noreplace means not to reinstall if the version chosen is the same version as that already installed (if installed). If there are no packages available, it's impossible to reach that check.

# emerge -p --noreplace foobar

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] app-portage/foobar-1.1 [1.0]

[Comment 2 Jason Stubbs (RETIRED) 2006-09-12 06:19:17 UTC]

(Didn't close in case somebody thinks it worth changing the behaviour of --noreplace)

[Comment 3 Åsmund Grammeltvedt 2006-09-12 06:37:33 UTC]

Hm, seems like my last reponse got lost somewhere.

My main issue with this behaviour is that it makes it difficult to provide a set of binary packages and have a host use these to upgrade _if_ a newer version of an  installed package is available. This is of course possible to achieve with some scripting, but the semantics of --usepkgonly and --noreplace appeared, based on the emerge(1) documentation, to provide what I wanted.

Anyway, thanks for the clarifying comments.

[Comment 4 Marius Mauch (RETIRED) 2006-09-19 05:38:53 UTC]

As Jason said.
The only viable alternative IMHO would be to treat vdb as another binrepo to use for --usepkgonly, but that would be another bug.