It's obvious to anyone, but not to users While i don't use myself preserved-libs, i think it would help users if --usepkg=n was default set when @preserved-libs is used Or if not, maybe change the portage message to: " Use emerge --usepkg=n @preserved-rebuild to rebuild packages using these libraries " as a better instruction for users Reproducible: Always Actual Results: if anyone is lost (really, i said it was obvious), the reason is simple, portage should never emerge a binary made on a system when the user is actually asking to emerge @preserved-libs
What if you are using a binhost and you've just run @preserved-rebuild on the binhost so it already has fixed binpkgs ready to use on your client with --usepkg=y?
then you could --usepkg=y :) compares your case with a "classic" case i think your case is less common, and if we don't set the option as default but only change the message, it's even easier for everyone you are perfectly aware you should not pass --usepkg=n users that are unaware of "mostly" anything should pass --usepkg because portage has told them to do it
the audience i aim for this change is certainly not a gentoo dev :D
I'm not sure that the audience who builds & reuses binpkgs locally on one machine, is larger than the audience who builds them on a build box with --usepkg=n always set. Using binpkgs is somewhat of an advanced topic. This is still up for debate, whether there should be a warning, or change the default behavior. But I don't think it's as black and white as your initial proposal. Personally I am against changing the default behavior, I think it's your responsibility to ask for the behavior you want from emerge here.
if you want take it black or white strictly, we can compares the result in both cases: your buildhost user will endup with portage not using his binary but building the package, which might be slow or whatever, but if the user let it do, it endup with a working system and no more the "emerge @preserved-libs" message while users not giving --usepkg=n will emerge again and again @preserved-libs without any changes, and will always have the message so my version of the message (ask them to --usepkg=n) would endup as both users case to get ride properly of the "do emerge @preserved-libs" message
(In reply to Ben Kohler from comment #1) > What if you are using a binhost and you've just run @preserved-rebuild on > the binhost so it already has fixed binpkgs ready to use on your client with > --usepkg=y? # EMERGE_DEFAULT_OPTS= emerge @preserved-rebuild Calculating dependencies... done! [ebuild U ] x11-libs/vte-0.64.1 [0.62.2] [binary R ] media-sound/pamixer-1.4-1 [ebuild R ] www-client/firefox-84.0_rc2 Does that binary 'R' pamixer package mean that it will just re-emerge it without rebuild? then why even bother listing it ? it's already emerged/installed, is it not? am I missing something? I'm not using a binhost, this is just on localhost, keeping binaries on it just in case it wants something I've already built in the past. I have to add --getbinpkg=n in order to get this: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-libs/vte-0.64.1 [0.62.2] [ebuild R ] media-sound/pamixer-1.4 [ebuild R ] www-client/firefox-84.0_rc2 an actual desire to rebuild pamixer, that is. So, maybe that arg should be implied? unless I'm missing something
(In reply to Adjudicator Darren from comment #6) > (In reply to Ben Kohler from comment #1) > > What if you are using a binhost and you've just run @preserved-rebuild on > > the binhost so it already has fixed binpkgs ready to use on your client with > > --usepkg=y? > > # EMERGE_DEFAULT_OPTS= emerge @preserved-rebuild > Calculating dependencies... done! > [ebuild U ] x11-libs/vte-0.64.1 [0.62.2] > [binary R ] media-sound/pamixer-1.4-1 > [ebuild R ] www-client/firefox-84.0_rc2 > > Does that binary 'R' pamixer package mean that it will just re-emerge it > without rebuild? then why even bother listing it ? it's already > emerged/installed, is it not? am I missing something? > > I'm not using a binhost, this is just on localhost, keeping binaries on it > just in case it wants something I've already built in the past. > > I have to add --getbinpkg=n in order to get this: > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild U ] x11-libs/vte-0.64.1 [0.62.2] > [ebuild R ] media-sound/pamixer-1.4 > [ebuild R ] www-client/firefox-84.0_rc2 > > an actual desire to rebuild pamixer, that is. > > So, maybe that arg should be implied? unless I'm missing something Package sets do not imply emerge arguments. I don't know if that would work well. Besides, binhost users would want the opposite behavior, as you already know. The @preserved-rebuild package set was never an optimal solution for anything, and it's functionality has always been very limited. Today, the preferred way to trigger rebuilds of this sort is with slot operators.
(In reply to Adjudicator Darren from comment #6) > (In reply to Ben Kohler from comment #1) > > What if you are using a binhost and you've just run @preserved-rebuild on > > the binhost so it already has fixed binpkgs ready to use on your client with > > --usepkg=y? > > # EMERGE_DEFAULT_OPTS= emerge @preserved-rebuild > Calculating dependencies... done! > [ebuild U ] x11-libs/vte-0.64.1 [0.62.2] > [binary R ] media-sound/pamixer-1.4-1 > [ebuild R ] www-client/firefox-84.0_rc2 > > Does that binary 'R' pamixer package mean that it will just re-emerge it > without rebuild? then why even bother listing it ? it's already > emerged/installed, is it not? am I missing something? > > I'm not using a binhost, this is just on localhost, keeping binaries on it > just in case it wants something I've already built in the past. If you were using a binhost, then you might have already performed @preserved-rebuild on the binhost, in which case it's valid to use the binary packages which were already rebuilt.
Alright that all makes sense, thank you for helping me understand this.