Provide a way to upgrade the msys install coming with ghcup.

[AndreasPK]

I've recently learned that ghcup comes with a msys install, but it does not provide a built in way to upgrade it.

I discovered this through a unrelated bug where a binary from this msys version has managed to make it's way into the ghc build system.

While a bug on it's own, it made me realize that ghcup (and configure via cabal as a result) was using a 5 year old version of bash which can cause issues with newer configure scripts. (As happened for libffi in ghc's case).

Perhaps ghcup could provide some sort of "upgrade msys" command, and record the time of the last update and record that as a sort of version number.

But I understand that a reasonable UI here is challenging given how msys works.

[jasagredo]

Wouldn't ghcup run -m -- pacman -Syuu twice suffice? Not sure if that is the right syntax though

[hasufell]

So.

There's a big design difference between:

• the ghcup bootstrap script (this is doing the msys2 install)
• the ghcup binary (this only knows of msys2 through an env var)

The binary is strictly unix. It doesn't deal with msys2 directly, because there is no clean way to update it. It's a mutable mess.

So the fact that ghcup doesn't really know about the state of msys2 is deliberate. That's up to pacman.

[hasufell]

Note that we already create a desktop url shortcut to the msys documentation:

ghcup-hs/scripts/bootstrap/bootstrap-haskell.ps1

Line 654 in 1fc6ddc

Create-Shortcut -SourceExe 'https://www.msys2.org/docs/package-management' -ArgumentsToSourceExe '' -DestinationPath 'Mingw package management docs.url' -TempPath $GhcupDir

Pointing to https://www.msys2.org/docs/package-management

[AndreasPK]

Note that we already create a desktop url shortcut to the msys documentation:

Funnily enough, my ghcup install predates the change that also adds those shortcuts. So I suppose this already got better over time.

Wouldn't ghcup run -m -- pacman -Syuu twice suffice? Not sure if that is the right syntax though

I've updated it by starting the relevant msys shell and doing the update from there. This is more about user having to:

• Know that ghcup does come with a msys environment
• Need to know how to update it.

I until very recently know the later but didn't actually realize the former!

Perhaps the framing in my issue wasn't quite optimal, as it focused too much on the second point. I think knowing that there is a msys env that is potentially relevant when you use ghc/cabal via ghcup is important but not that obvious if you "just use it".

It's a mutable mess.

Definitely true

---

I think it would be quite reasonable and actionable for ghcup upgrade to inspect the pacman log to check for the last time something was updated and complain once that is a long time ago.

In a similar fashion to how cabal complains about the hackage data being stale if you haven't updated it for a long time.

If a user wants to upgrade ghcup but hasn't updated ghcups msys env in two years, that's probably not intentional.

[hasufell]

In a similar fashion to how cabal complains about the hackage data being stale if you haven't updated it for a long time.

That's quite different. The hackage index is maintained by cabal itself. It knows about where the files are etc.

GHCup and pacman are two different programs that know nothing about each other.

Also see https://www.haskell.org/ghcup/about/#non-goals

Invoking package managers is explicitly against ghcup philosophy. So even if it had a proper API, we'd still not use it.

Doing fuzzy timestamp checks would be a possibility, but it's not very exciting.

[AndreasPK]

I think ghcup not doing the upgrade/invoking pacman itself is fine. I was thinking more along the lines of a warning based on the timestamps in the pacman log. Which I assume you refer to as doing fuzzy timestamp checks.

Something like this on ghc upgrade

It seems you are upgrading ghcup but according to you haven't updated ghcups msys env for 1377 days. If you want to update your mys env you can read more about how to do so here:

I've mostly opened this ticket because figuring out something is broken because the msys env provides a outdated bash doesn't seem like something that's straightforward for most windows users to do. So while I imagine not many people will run into an issue like this, it can be very painful for those that do.

[hasufell]

I think there might be another way. I'm guessing you're mainly opening the msys2 shell (which is bash) via the desktop shortcut. Maybe we could, upon opening said shell, print a message informing the user along the lines of:

To keep your msys2 env and bash shell up to date, run 'pacman -Syuu'.

This also has a higher chance of crossing the users eyes than a message that's only visible on ghcup upgrade.