| Summary: | Feature request: emerge --skipfirst shouldn't imply --resume | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Lónyai Gergely <alephlg> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | coldwind |
| Priority: | Lowest | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 184128 | ||
|
Description
Lónyai Gergely
2007-12-03 09:08:26 UTC
Please view the bug #201060 Maybe you could tell us what should that exactly do? If a system's package not compiled, but i not will masking in the packages.mask and running the "emerge -u world" command, the top a update-list.
If i running a "emerge -u --skipfirst world" in place of ("emerge -u world" + "CTRL+C" + "emerge --resume --skipfirst"), i so happy.
Please the "--skipfirst" function's applying in after the packages-list generation. This may drop anytime and anylist's first atom.
I really fail to see how's this useful, since you have no control whatsoever on what ends up as 'first' for emerge -u world. I use the eix-sync and this is in the sync's end write the upgraded/new/removed packages. And i've some similar gentoo-machine so i draw a easy conclusion. (In reply to comment #4) > I really fail to see how's this useful, since you have no control whatsoever on > what ends up as 'first' for emerge -u world. > What about emerge -pu world ; emerge --skipfirst -u world? There's no reason for --skipfirst implying --resume. (In reply to comment #6) > What about emerge -pu world ; emerge --skipfirst -u world? There's no reason > for --skipfirst implying --resume. For the above use case, the appropriate action would be to mask the first package shown in the `emerge -pu world` output. Why not just mask the package if you don't want it? Rather than extend the functionality of --skipfirst, I'd prefer to remove it as an option entirely. I don't think there is ever a really a good reason to bypass the dependency resolver like --skipfirst does. For all the use cases I've seen, it would be more appropriate to mask the unwanted package and recalculate dependencies. I'm planning to implement an automated way to do that soon, as a fix for bug 12768. (In reply to comment #7) > Rather than extend the functionality of --skipfirst, I'd prefer to remove it as > an option entirely. That looks even much better to me ;-) (In reply to comment #7) Spot on, the only usage I've seen is people misusing this as a 'replacement' for feature requested in Bug 12768. It really should be just removed. Well, IMO the main use case for --resume (and therefore --skipfirst) is to complete a failed --emtpytree operation after the failing package was manually merged, how would you retain that functionality without --skipfirst? (In reply to comment #10) > Well, IMO the main use case for --resume (and therefore --skipfirst) is to > complete a failed --emtpytree operation after the failing package was manually > merged, how would you retain that functionality without --skipfirst? I described one solution for that in bug 199408#c5: > I suppose that we can create a package set that selects all packages installed > before a certain time. There is a counter that is incremented whenever a > package is installed, so we could implement it using the counter instead of > relying on timestamps. (In reply to comment #11) > (In reply to comment #10) > > Well, IMO the main use case for --resume (and therefore --skipfirst) is to > > complete a failed --emtpytree operation after the failing package was manually > > merged, how would you retain that functionality without --skipfirst? > > I described one solution for that in bug 199408#c5: > > I suppose that we can create a package set that selects all packages installed > > before a certain time. There is a counter that is incremented whenever a > > package is installed, so we could implement it using the counter instead of > > relying on timestamps. Hmm, I guess that could work as a reasonable alternative. BTW, Bug 16342 has a lot more meaningful generic suggestion than this one. See comment #13 |
