Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 464264 - sys-apps/portage-2.1.11.55 binary package triggering a rebuild
Summary: sys-apps/portage-2.1.11.55 binary package triggering a rebuild
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-03 01:58 UTC by David Flogeras
Modified: 2013-04-03 03:05 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Flogeras 2013-04-03 01:58:16 UTC
I'm really not sure if this is a bug or by design. I have a system which I use a more powerful system to build binaries for in a chroot.   When updating the target, the package libarchive triggered a 'r' (rebuild) on kde-base/ark as it should.  However it didn't use the binary from the binhost, it wanted to rebuild from source on the target.

Reproducible: Always
Comment 1 Zac Medico gentoo-dev 2013-04-03 02:48:21 UTC
There are many factors that can cause results to vary. Here are some common cases:

1) If the target system has different USE settings, then you can use --binpkg-respect-use=n to make it try to choose the binary package even when building it from source would result in different USE settings.

2) If the binary package was built different KEYWORDS that the ebuild currently has, and the binary package is masked by KEYWORDS on the target system, then you may need to adjust /etc/portage/package.accept_keywords on the target system.

3) If the binary package corresponds to an ebuild version which is no longer available in the current portage tree, then in will be rejected in favor of an ebuild which is currently available.

There may be other reasons that I've forgotten to mention. The --usepkgonly option can help for cases (1) and (3).
Comment 2 David Flogeras 2013-04-03 03:05:02 UTC
Thanks Zac for the very exact response :)

It seems it was probably just a combination of #2 and poor timing.  When I built/installed the binpackages last week kde-base/ark was in ~x86.  Since then they had been stabled, and I didn't do a full bin rebuild.  Rebuilding ark on the server fixed it up and explains it perfectly.  Just wanted to make sure I didn't accidentally discover a bug.  Closing.