Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 490350 - sys-apps/portage: Extended user interface of --ignore-built-slot-operator-deps=y
Summary: sys-apps/portage: Extended user interface of --ignore-built-slot-operator-deps=y
Status: CONFIRMED
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: 2013-11-04 07:42 UTC by Martin Väth
Modified: 2014-04-26 23:25 UTC (History)
6 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 Martin Väth 2013-11-04 07:42:56 UTC
I open this bug on the suggestion of hasufell, since this came up in a discussion on user experience on the gentoo-user mailing list.

In contrast to @preserved-rebuild or revdep-rebuild, users are now "forced" by default to reemerge packages pulled in by EAPI=5 subslot dependencies. For users with not so powerful machines this has the disadvantage that (in contrast to @preserved-rebuild or revdep-rebuild) it is not so easy for users to postpone these reemerges to some later moment.

Technically, users have this possibility, since they can use explicitly --ignore-built-slot-operator-deps=y or put it into their EMERGE_DEFAULT_OPTS, but this has the disadvantage that either they have to call portage a second time with clumsy parameters (which, moreover, on less powerful machines takes a considerable amount of time), and in the EMERGE_DEFAULT_OPTS case, they are not even informed that (and which) reemerges are recommended. Moreover, a command analogous to @preserved-rebuild/revdep-rebuild is missing in the second case.

I have some suggestions which could improve this situation. (Even if only one or two of them are implemented it might improve user experience IMHO):

1. In mode --ask, the user can enter instead of "yes" or "no" also "without packages only marked by r" (I am not a native English speaker, so you probably know a better wording than me). Alternatively, a second question might be asked after "yes".

2. Add something like --ignore-built-slot-operator-deps=show (or alternatively a FEATURE which becomes active in case of --ignore-built-slot-operator-deps=y) which *shows* only which packages would be of "r" type, without including them into the list of packages to be emerged. This way, the user would at least get informed which *should* better be reemerged (analogously to the messages which etc-update files are still outstanding; IIRC also FEATURES=preserved-rebuild has such a message.)

3. Add an option (or package set) which allows to do only the "r" packages (analogously to @preserved-rebuild) so that the user can at some later point emerge the packages which he had previously postponed by --ignore-build-slot-operator-deps=y (or by 1.) and thus get the system into a running state, without being forced to do a full world update (which might add a lot of additional "r" packages at this later point...).
Since this is analogous to @preserved-rebuild, from the user's point of view the ideal case would be an implementation as a package set; however, I am aware that the latter contradicts the current internal handling of package sets, since the content of this set would depend on what else is on the command line, so I guess that even if the set syntax is chosen, internally it would need to be implemented as an option, anyway.
Comment 1 Sebastian Luther (few) 2013-11-26 20:49:38 UTC
Number 1 and 2) are rather problematic, because the difference between the two merge lists produced by y and n might be larger than omitting the 'r' packages. For example a rebuild could also be an update which might require updates to other packages. This could cause new problems like slot conflicts, blockers, etc.

I'd rather not explain two (possibly) completely different results to the user at the same time.

Number 3) Sounds manageable. I don't understand what else other than @<set-name> you want to put on the command line though.

I image something like: emerge @rebuilds, that would rebuild every package that has a broken slot operator dependency.
Comment 2 Martin Väth 2013-11-27 09:09:07 UTC
(In reply to Sebastian Luther (few) from comment #1)
> Number 1 and 2) are rather problematic, because the difference between the
> two merge lists produced by y and n might be larger than omitting the 'r'
> packages. For example a rebuild could also be an update which might require
> updates to other packages.

This won't happen with -Du @world which is the main use case (and maybe one can restrict the feature to that case), but this was not my point:

I think for 1. and 2. most users would be OK with the list which you now get with --ignore-built-slot-operator-deps=n, only that the packages with only [r] (and not [U]) are conditionally not rebuilt/only shown - similarly as if they had been specified with --exclude.

In fact, this is probably what most users do currently: They do *not* use --ignore-built-slot-operator-deps=y, but if they have no time for rebuilding the [r] packages, they call the same emerge command again with --exclude for these packages. But the idea of --ask is that they (normally) should not have to call emerge again (and especially not wait until portage recalculates the same filelist again...)

> Number 3) Sounds manageable. I don't understand what else other than
> @<set-name> you want to put on the command line though.

I though about an option. From the user-perspective @<set-name> is certainly more intuitive than an option, but I guess for the implementation it is hard to treat it like a normal set, because you have to resolve dependencies before you know the content of the set (which is rather different from how sets are handled internally, currently).
Comment 3 Sebastian Luther (few) 2013-11-27 09:49:55 UTC
(In reply to Martin Väth from comment #2)
> (In reply to Sebastian Luther (few) from comment #1)
> > Number 1 and 2) are rather problematic, because the difference between the
> > two merge lists produced by y and n might be larger than omitting the 'r'
> > packages. For example a rebuild could also be an update which might require
> > updates to other packages.
> 
> This won't happen with -Du @world which is the main use case (and maybe one
> can restrict the feature to that case), but this was not my point:
> 
> I think for 1. and 2. most users would be OK with the list which you now get
> with --ignore-built-slot-operator-deps=n, only that the packages with only
> [r] (and not [U]) are conditionally not rebuilt/only shown - similarly as if
> they had been specified with --exclude.
> 
> In fact, this is probably what most users do currently: They do *not* use
> --ignore-built-slot-operator-deps=y, but if they have no time for rebuilding
> the [r] packages, they call the same emerge command again with --exclude for
> these packages. But the idea of --ask is that they (normally) should not
> have to call emerge again (and especially not wait until portage
> recalculates the same filelist again...)

Suppose the merge list with 'y' would be:
[rR ] app-misc/A-1
[  N] app-misc/B-1
with 'n' the list would be empty. app-misc/B-1 is only there because it is needed to install A-1 (i.e. changed dep in the ebuild, missing build time dependency, A-1 might infect be an update because the old version is no longer available).

Do users really want to install B if they say 'no' to "Include the 'r' packages?"?
> 
> > Number 3) Sounds manageable. I don't understand what else other than
> > @<set-name> you want to put on the command line though.
> 
> I though about an option. From the user-perspective @<set-name> is certainly
> more intuitive than an option, but I guess for the implementation it is hard
> to treat it like a normal set, because you have to resolve dependencies
> before you know the content of the set (which is rather different from how
> sets are handled internally, currently).

I thought about not doing a full dependency resolution to construct the set. I thought about going through all installed packages and then satisfying their *DEPENDs using other installed packages. If something is unsatisfied because of a slot operator dep and could be satisfied by a rebuild, then the package belongs to the set.

I'd have to check if that's currently possible, so you might be right that it's not practical to implement it as set.
Comment 4 Martin Väth 2013-11-27 10:40:28 UTC
(In reply to Sebastian Luther (few) from comment #3)
> Suppose the merge list with 'y' would be:
> [rR ] app-misc/A-1
> [  N] app-misc/B-1
> with 'n' the list would be empty. app-misc/B-1 is only there because it is
> needed to install A-1 (i.e. changed dep in the ebuild, missing build time
> dependency, A-1 might infect be an update because the old version is no
> longer available).

Yes, I would say users typically would want to have B installed.
In fact, typically users want to have --with-bdeps=y unless they have a very special setup (embedded or binary-only; I guess the --with-bdeps=n default is only for historical reasons).

If users do not agree they can still use --ignore-built-slot-operator-deps=y or --exclude, but the case you mention is really not the typical case. It can happen only in exotic situations when:

1. The user intentionally unmerged the build-time dependency B.
2. The user is on a binary-only host but does not have a current binary version of A.

In any case, implementing the feature with "forced" B will not do any harm, since it is an additional *feature* and not restricting anything which happened before: For many users the additional choice given by the feature is useful. There might be some cases (like ub the above exotic situations when users might really not want B) in which the new choice is not that useful, but is this a reason to not offer this choice at all?
Comment 5 Sebastian Luther (few) 2013-11-27 12:06:01 UTC
Lets take a step back and discuss the handling of rebuilds in general. Maybe we can find a better way of dealing with this problem than --ignore-built-slot-operator-deps=y/n.

I send a mail to the portage dev list today.