Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 199408 - reimplement `emerge --resume` to account for current configuration
Summary: reimplement `emerge --resume` to account for current configuration
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 183683 (view as bug list)
Depends on:
Blocks: 155723 261959
  Show dependency tree
 
Reported: 2007-11-16 22:58 UTC by Mark
Modified: 2010-09-23 01:58 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 Mark 2007-11-16 22:58:33 UTC
Emerge a lot of packages (i.e 'emerge -e world'), stop it, mask the package at the top of the list via /etc/portage/package.mask (i.e because of a broken package).

Do a 'emerge --resume' and the package isn't masked like it should be.

Sorry if this isn't clear enough, its my first bug report :)

Reproducible: Always

Steps to Reproduce:
1. emerge -e world
2. stop it (ctrl-c)
3. mask package next in line via /etc/portage/package.mask
4. emerge --resume
Actual Results:  
package isn't masked

Expected Results:  
package should be masked, and lower version should be installed

Checked to see if changes have been masked between cancelling and resuming
Comment 1 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-11-16 23:12:51 UTC
(In reply to comment #0)
> mask the package at the top of the list via /etc/portage/package.mask (i.e
> because of a broken package).

Use `emerge --resume --skipfirst`.
Comment 2 Mark 2007-11-16 23:21:58 UTC
The problem is that i don't want to skip it, as it needs rebuilding
Comment 3 Andrew Gaffney (RETIRED) gentoo-dev 2007-11-16 23:45:22 UTC
That still doesn't make any sense. Of course you want to skip it if you're sticking it in package.mask.
Comment 4 Mark 2007-11-16 23:55:34 UTC
I don't want to mask the whole package, just the version with compile problems. I've worked around it now, just thought it was something that should be looked into
Comment 5 Zac Medico gentoo-dev 2007-11-17 00:26:35 UTC
I've been planning to make --resume build a dependency graph, and that will include handling of masked packages.

Tracking the state for a command like `emerge -e world` is a separate problem. 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.
Comment 6 Mark 2007-11-17 00:33:05 UTC
Sounds good
Comment 7 Marius Mauch (RETIRED) gentoo-dev 2008-03-02 15:13:43 UTC
*** Bug 183683 has been marked as a duplicate of this bug. ***
Comment 8 Zac Medico gentoo-dev 2008-05-06 08:30:34 UTC
In 2.1.5_rc7 this is partially fixed in the sense that --resume commands now include dependency calculations. The current support is quite minimal but it is is useful for detecting problems with the resume list such as missing dependencies and masked packages.
Comment 9 Zac Medico gentoo-dev 2009-01-21 22:17:31 UTC
The behavior since portage-2.1.5 is to drop masked packages if --skip-first is given, and bail out otherwise.

I suppose it would be alright to make it behave this way any time that the --resume option is used. However, now that the --keep-going option is available, you'll probably just use that instead of --resume/--skipfirst.
Comment 10 Zac Medico gentoo-dev 2009-01-21 22:51:12 UTC
In svn r12543 I've changed to behavior to drop masked packages even when the --skipfirst is not enabled.
Comment 11 Randall Wald 2009-01-31 21:08:33 UTC
A related problem I've run into (especially when upgrading gcc) is that sometimes emerge -e world will fail because the stable version of a package doesn't work, but the ~arch version of said package does work. In these cases, it would be nice to be able to modify /etc/portage/package.keywords and then have emerge --resume take the new file into account. Would this be a good addition to portage, or does it have too many potential consequences?

Oh, and just emerging the ~arch version separately and then running emerge --resume --skipfirst doesn't work, because emerge --resume doesn't reliably put things in the same order; because of the new dependency checking, the last package to fail isn't always the first package to be tried the next time.
Comment 12 Zac Medico gentoo-dev 2009-02-01 00:01:03 UTC
(In reply to comment #11)
> A related problem I've run into (especially when upgrading gcc) is that
> sometimes emerge -e world will fail because the stable version of a package
> doesn't work, but the ~arch version of said package does work. In these cases,
> it would be nice to be able to modify /etc/portage/package.keywords and then
> have emerge --resume take the new file into account. Would this be a good
> addition to portage, or does it have too many potential consequences?

It goes beyond the scope of --resume to select new packages, and I'd rather not got there. The real problem that you're trying to solve here is to select the specific packages which you want to rebuild (you don't want to rebuild packages which you've already rebuilt). One possible solution for this type of problem is to use AgeSet (requires portage-2.2) as suggested in bug #247106, comment #2.

> Oh, and just emerging the ~arch version separately and then running emerge
> --resume --skipfirst doesn't work, because emerge --resume doesn't reliably put
> things in the same order; because of the new dependency checking, the last
> package to fail isn't always the first package to be tried the next time.

This is actually due to an interaction with --jobs which is described in bug #247106, comment #7. With the patch that's currently in svn you'll be able to mask the unwanted package and just run emerge --resume (without --skipfirst).


Comment 13 Zac Medico gentoo-dev 2009-03-10 09:34:03 UTC
This is fixed in 2.2_rc24 which is in package.mask. I'll close this bug when it's also released in 2.1.6.8.
Comment 14 Zac Medico gentoo-dev 2009-03-13 20:39:56 UTC
This is released in 2.1.6.8.