with these emerge options: --jobs --keep-going --newrepo --newuse --changed-use --changed-deps --changed-slot --deep --tree --unordered-display --backtrack=3000 --complete-graph --with-bdeps=y --rebuild-if-new-rev --rebuild-if-new-ver --rebuild-if-unbuilt --rebuilt-binaries --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y I regularly see many dozens of packages scheduled for rebuild because one of their dependencies is updated (this is desired for me). However, if the emerge process is interrupted (e.g. system reboot), running emerge a second time, with identical options, does not result in the list of packages to be merged being complete when compared to the first run. What appears to be happening here is that emerge is calculating the packages to rebuild based on the packages currently scheduled for rebuild / update / changed use, but there's no way to ask emerge to force the whole system to be made consistent. Potentially a way to address this would be to track the versions, use flags, and recursive dependencies (with use flags and versions) of each package. This would allow the ability to detect when an installed package is in need of rebuilding based on comparing against the other packages installed on the system Reproducible: Always
The large --backtrack=3000 value shows that it is difficult for the dependency resolver to converge on an "optimal" state for your system. (In reply to Michael Jones from comment #0) > However, if the emerge process is interrupted (e.g. system reboot), running > emerge a second time, with identical options, does not result in the list of > packages to be merged being complete when compared to the first run. If you can use package.mask entries to limit the search space, then that should help reduce the backtracking and lead to more reproducible results. > What appears to be happening here is that emerge is calculating the packages > to rebuild based on the packages currently scheduled for rebuild / update / > changed use, but there's no way to ask emerge to force the whole system to > be made consistent. Every single calculation aims for a consistent state, as long as you have not used --complete-graph=n. > Potentially a way to address this would be to track the versions, use flags, > and recursive dependencies (with use flags and versions) of each package. > This would allow the ability to detect when an installed package is in need > of rebuilding based on comparing against the other packages installed on the > system I'm not sure what you're getting at here, since we already track all the versions, use flags, and dependencies that are relevant.
> The large --backtrack=3000 value shows that it is difficult for the dependency resolver to converge on an "optimal" state for your system. I'm not really following. This option was added because portage was regularly failing to resolve dependencies, but it's been there for many years. Is there some problem with this option? > If you can use package.mask entries to limit the search space, then that should help reduce the backtracking and lead to more reproducible results. Could you elaborate on how this relates to a second run of emerge fails to rebuild packages which were (in the first run) scheduled for rebuild because one of their dependencies was rebuilt? > Every single calculation aims for a consistent state, as long as you have not used --complete-graph=n. > I'm not sure what you're getting at here, since we already track all the versions, use flags, and dependencies that are relevant. I mean, this is obviously not the case, at least for what I'm referring to. The problem here is that if, for example, glibc is updated to a new version, emerge will schedule some 300 packages for rebuild. If I let emerge rebuild 100 of those 300, and then my system reboots, re-running emerge with the exact same arguments might say that there's nothing to do, or only 5-10 packages need rebuilt.
It's very possible it's a specific defect of --rebuild-if-new* or similar. It's hard to know without example output (or, ideally, a reduced testcase). You only gave details of an example scenario just now.
Is there a specific option i can set, or log file I can save, that will help demonstrate what I'm referring to the next time I reproduce this problem? I thought I had provided enough context to explain what was going on, but it's a difficult to describe problem.
Oh right, the -rebuild-if-* options are not going to trigger rebuilds for past updates if emerge is interrupted. However, you could use emerge --resume to salvage the previous package list.
