Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 716798 - sys-apps/portage @preserved-libs should imply --usepkg=n
Summary: sys-apps/portage @preserved-libs should imply --usepkg=n
Status: RESOLVED CANTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 12:04 UTC by nobody
Modified: 2022-07-28 04:49 UTC (History)
2 users (show)

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 nobody 2020-04-09 12:04:48 UTC
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
Comment 1 Ben Kohler gentoo-dev 2020-04-09 12:11:41 UTC
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?
Comment 2 nobody 2020-04-09 12:21:12 UTC
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
Comment 3 nobody 2020-04-09 12:22:32 UTC
the audience i aim for this change is certainly not a gentoo dev :D
Comment 4 Ben Kohler gentoo-dev 2020-04-09 12:26:46 UTC
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.
Comment 5 nobody 2020-04-09 12:57:28 UTC
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
Comment 6 Adjudicator Darren 2021-05-08 00:52:26 UTC
(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
Comment 7 Zac Medico gentoo-dev 2021-05-08 05:13:47 UTC
(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.
Comment 8 Zac Medico gentoo-dev 2021-05-08 05:24:30 UTC
(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.
Comment 9 Adjudicator Darren 2021-05-08 12:21:21 UTC
Alright that all makes sense, thank you for helping me understand this.