Consider the following setting which is perhaps not so rare: Packages are upgraded frequently on a "fast" machine with FEATURES=buildpkg, and occasionally (say, once a month) a slow machine should be sync'ed with the built binary packages. In this setting, several of the binary packages are ignored by portage on the slow machine. The reason is that such a package was emerged on the fast machine with some entry in /etc/portage/package.keywords (e.g. with some ~x86 keyword), but at the much later time when the slow machine is sync'ed the corresponding version has become x86, and so the entry from /etc/portage/package.keywords was removed: Unfortunately, portage does not take the current KEYWORDS from the ebuild, but the obsolete ones stored in the binary package. In my opinion, the best solution would be that - if KEYWORDS information for the same version and overlay are available from an ebuild/metadata cache - portage should ignore the KEYWORDS stored in the binary package: The version and overlay should uniquely determine the binary package so that it should not cause any problems to do this. If you dislike this idea, I can think of the alternative to let the user decide: How about a switch to portage to do the above at least optionally? Or a less intrusive change: How about a tool to upgrad the KEYWORDS in the binary packages to the current state in the tree? This is at least faster than having to recompile the whole package on the slow machine just because it was stabilized meanwhile...
KEYWORDS aren't the only issue. There's also desire to update *DEPEND, as expressed in bug 282927 and on the chromium-os-dev mailing list here: http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/c9501ca5f647ace1
i think this is correct behavior. it allows you to not need the ebuilds at all on the machine emerging binpkgs. so if there is a change, it'd have to be a new emerge flag defaulting to off (so current behavior is retained). or you script something to tweak the KEYWORDS value in your binpkgs. should be trivial with qtbz2/qxpak utilities. although perhaps those utilities could be extended to allow for inline editing ... file a new bug ;).
Isn't the --use-ebuild-visibility option what you want?
(In reply to comment #2) > i think this is correct behavior. it allows you to not need the ebuilds > at all on the machine emerging binpkgs. Maybe this was not clear enough in my original posting: ... *If* KEYWORDS information for the same version and overlay are available from an ebuild/metadata cache ... (According to Zac's remark, I should have spoken even about metadata information instead of KEYWORDS information.) Of course, if there is no such information, the one from the binary should be taken, but if there is such data, this should obsolete the one from the binary (in my opinion, by default, but I do not argue if you think only if explicitly required). > so if there is a change, it'd have to be a new emerge flag defaulting > to off The problem is not "*defaulting* to off": I would not have filed a bug if this were only a default the user could simply override. The problem is that the user is not asked, i.e. he has no choice: He *cannot* install the binary package (unless he hacks around the binary package). > or you script something to tweak the KEYWORDS value in your binpkgs. I am not strictly against this solution if it were built into portage: Analogously to the FEATURE of updating binary packages for package moves, there should be a FEATURE to updating binary packages for KEYWORDS/metadata changes (or at least e.g. fixpackages should be able to update this information). > should be trivial with qtbz2/qxpak utilities. Trivial only if this script is part of portage since the script needs access to the correct metadata. (Of course, I could write a hack for myself, but I think to install a binary package you had built earlier is something which shouldn't require a hack.)
(In reply to comment #3) > Isn't the --use-ebuild-visibility option what you want? The description sounds as if this could be exactly what I want, but it does not seem to work: I tried on an x86 system $ FEATURES=buildpkg ACCEPT_KEYWORDS="~x86" emerge -1 blas-reference $ # Turn ~x86 to x86 in /usr/portage/metadata/cache and in $ # /usr/portage/sci-libs/blas-reference/blas-reference-20070226-r1.ebuild $ ebuild \ /usr/portage/sci-libs/blas-reference/blas-reference-20070226-r1.ebuild \ manifest >>> Creating Manifest for /porttree/portage/sci-libs/blas-reference $ rm -rf /var/cache/edb/dep/* $ emerge -1ak --use-ebuild-visibility=True blas-reference and it wants to rebuild the ebuild and ignores the built binary package. (The binary package is used if I revert the changes and use ACCEPT_KEYWORDS='~x86').
(In reply to comment #5) > The description sounds as if this could be exactly what I want, > but it does not seem to work: Currently this option only does something if --use-ebuild-visibility=n and --usepkgonly, in which case it will reject an installed package due to missing keywords. However, I think we may be able to use part of the new autounmask framework to make it behave like you want. Basically, it will autounmask the binary package with missing KEYWORDS, and it won't prompt the user for configuration changes (unlike other autounmask cases).
and like i already said, this is often desired behavior. your proposal was to always ignore the binpkg in favor of the ebuild tree and i said that is wrong. a new option is acceptable as it retains existing behavior by default.
(In reply to SpanKY from comment #7) > and like i already said, this is often desired behavior. your proposal was > to always ignore the binpkg in favor of the ebuild tree and i said that is > wrong. a new option is acceptable as it retains existing behavior by > default. 12 years later, I don't see why this behavior would be desired. It's not guaranteed to be possible to upgrade a Gentoo system without the Gentoo repository using only a binpkg repository (pkgmoves are one way I've seen this break in practice). And further, if keywords are dropped from a package, there's no way to propagate that to any binpkgs that might have been generated while the package had keywords, leading to -K/-G installs having broken packages installed, which I've also experienced in practice. Take sys-apps/less-612, which was added to ::gentoo originally with normal keywords. One of my systems generated a binpkg from this version, and it was later dekeyworded in 30ac84215c055b7f664feba6644c88a612a634a5 (only the -+ lines for brevity): -KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" +#KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris" So, the PKGDIR still has keyworded binpkg for this package, according to ${PKGDIR}/Packages: CPV: sys-apps/less-612 [snip] KEYWORDS: ~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris [snip] PATH: sys-apps/less/less-612-1.xpak And thus, Portage will still upgrade to it, despite it being buggy (which lead to it being unkeyworded): # emerge -Gpv less Local copy of remote index is up-to-date and will be used. These are the packages that would be merged, in order: Calculating dependencies... done! [binary U ] sys-apps/less-612-1::gentoo [608-r1::gentoo] USE="pcre (-unicode%*)" 0 KiB Total: 1 package (1 upgrade, 1 binary), Size of downloads: 0 KiB In 2022, are there any concerns with relying on an ebuild repository for this metadata?
(In reply to John Helmert III from comment #8) > In 2022, are there any concerns with relying on an ebuild repository for > this metadata? Hah, or 2023 now :)
