Allow automatic calling of `emerge -DUu @world`

[hololeap]

haskell-updater is often the most useful when run in a loop, such as:

until emerge -DUu --keep-going
do
	haskell-updater -- @preserved-rebuild
done

It would be convenient to have the basic haskell-updater invocation support running a loop like this, especially for newcomers who might be confused as to why they have to repeatedly run haskell-updater during updates.

There could be a flag to choose from different options, including the original behavior, and with #17 the default could be changed and new options be added.

[hololeap]

I stumbled across the --reinstall-atoms flag for emerge which says in the man page:

--reinstall-atoms ATOMS
A space separated list of package names or slot atoms. Emerge will treat matching packages as if they are not installed, and reinstall them if necessary.

Using this seems to be an option for pulling in broken haskell packages using a world update:

emerge -DUu --keep-going @world --reinstall-atoms "$(haskell-updater -l | xargs -d'\n' echo)"

[l29ah]

And a world update can further break haskell packages, so you'll need to run haskell-updater afterwards regardless.

[hololeap]

The problem is, sometimes portage needs to pull in updates for haskell packages that are not yet broken, otherwise it can't sort out the dependency graph. This actually just happened to me:

Calculating dependencies... done!
Dependency resolution took 186.86 s (backtrack: 9/9999).


!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-haskell/hashable:0

  (dev-haskell/hashable-1.4.3.0:0/1.4.3.0::haskell, ebuild scheduled for merge) USE="doc hoogle hscolour profile test -random-initial-seed" ABI_X86="(64)" pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-haskell/hashable-1.4.2.0-r2:0/1.4.2.0::haskell, installed) USE="doc hoogle hscolour profile test -random-initial-seed" ABI_X86="(64)" pulled in by
    <dev-haskell/hashable-1.5:0/1.4.2.0=[profile] required by (dev-haskell/uuid-types-1.0.5.1:0/1.0.5.1::haskell, installed) USE="doc hoogle hscolour profile test" ABI_X86="(64)"
                             ^^^^^^^^^^^

    >=dev-haskell/hashable-1.2.7.0:0/1.4.2.0=[profile] required by (dev-haskell/uuid-types-1.0.5.1:0/1.0.5.1::haskell, installed) USE="doc hoogle hscolour profile test" ABI_X86="(64)"
                                  ^^^^^^^^^^^

The hack was to run haskell-updater -- ~dev-haskell/hashable-1.4.3.0 to force portage to pull that update in.

I think that haskell-updater pulling in @world is actually sensible and --reinstall-atoms lets us mark the broken ones so that they will be rebuilt no matter what. I'll do some testing on my end, and if it seems to work, I can add this as an optional mode for haskell-updater.

[hololeap]

Running the command in a loop seems to be working:

until emerge -DUu --keep-going @world --reinstall-atoms "$(haskell-updater -l | xargs -d'\n' echo)"; do sleep 1; done

although I had to add --ignore-built-slot-operator-deps=y to get portage unstuck at one point. It required this even with emerge --ignore-default-opts -DUu @world so it may be a portage bug.

This was when all non-haskell packages had been updated so the --ignore-built-slot-operator-deps=y wasn't harmful (since haskell packages pulled in by sub-slot operators will be rebuilt anyway), but this shouldn't be added by default during haskell-updater.

Ideally, we would be able to pull in all haskell packages that need an update, plus packages that are reported broken by ghc-pkg. Optionally, we could filter out packages that are not required by @world, which would be a way to avoid haskell-updater pulling in masked packages. This would require a way to interface with portage at a low level during dependency graph resolution.

Edit:

--reinstall-atoms sort of worked, but I eventually had to run the standard haskell-updater invocation since my experimental emerge invocation wasn't rebuilding all the necessary packages. This plus the --ignore-built-slot-operator-deps=y drama makes me think that --reinstall-atoms is buggy or at least doesn't behave the way I expected.