Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow automatic calling of emerge -DUu @world #18

Open
hololeap opened this issue Jan 8, 2023 · 4 comments
Open

Allow automatic calling of emerge -DUu @world #18

hololeap opened this issue Jan 8, 2023 · 4 comments
Labels
Feature Non-critical feature request

Comments

@hololeap
Copy link
Member

hololeap commented Jan 8, 2023

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 hololeap added the Feature Non-critical feature request label Jan 8, 2023
@hololeap
Copy link
Member Author

hololeap commented Mar 20, 2024

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
Copy link
Member

l29ah commented Mar 20, 2024

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

@hololeap
Copy link
Member Author

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
Copy link
Member Author

hololeap commented Mar 21, 2024

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.

hololeap added a commit that referenced this issue May 25, 2024
Add `--mode=reinstall-atoms` flag which uses experimental emerge
invocation (using `--reinstall-atoms`).

The rationale is that by marking broken packages by using
`--reinstall-atoms`, portage will pretend that they are not yet
installed, thus forcing their reinstallation. `--update` is
used and all installed Haskell packages are targeted so that the entire
Haskell environment is examined. This has a side-effect of skipping
packages that are masked or otherwise unavailable while still
rebuilding needed dependencies that have been broken.

A new `--target=world` option has been added exclusively for
`--mode=reinstall-atoms`, which sets the portage target to `@world`.
This will hopefully provide a way to update the entire system while
fixing broken Haskell packages as they appear.

Reorganize command line options quite a bit as well, adding `--mode`
and `--target` options as well as convenience/legacy aliases.

Bug: #18
Signed-off-by: hololeap <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Non-critical feature request
Projects
None yet
Development

No branches or pull requests

2 participants