Summary: | sys-apps/portage: Extended user interface of --ignore-built-slot-operator-deps=y | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Väth <martin> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | aklhfex, bernalex, bircoph, erikdenstore+gbugs, hasufell, rdalek1967 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Väth
2013-11-04 07:42:56 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. (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). (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. (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? 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. |