Main channel vs vanilla

[suhail-singh]

Continuing the discussion from #166.

How to determine the set of patches/fixes applied

For tools whose binaries are available in both main and vanilla channels,
say HLS 2.5.0.0, what are the differences in terms of the specific
"patches/fixes" (as stated in the README.md) that are applied to main? How
would an end-user of ghcup determine that?

Which takes precedence

If one were to enable the vanilla channel in addition to the main via
below, which channel would be given priority when installing tools whose
binaries are available in both channels?

ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-vanilla-0.0.8.yaml

Answering the above myself: ^ reading the source of config.yaml in ghcup-hs,
it's clear that later entries would win. I.e, in the example above vanilla
would take precedence over main. From config.yaml source:

# Where to get GHC/cabal/hls download info/versions from. This is a list that performs
# union over tool versions, preferring the later entries.

Thank you to both the upstream and ghcup maintainers for their continued
efforts.

[hasufell]

For tools whose binaries are available in both main and vanilla channels,
say HLS 2.5.0.0, what are the differences in terms of the specific
"patches/fixes" (as stated in the README.md) that are applied to main? How
would an end-user of ghcup determine that?

Source code patches are communicated via post-install messages with links. See

ghcup-metadata/ghcup-0.0.8.yaml

Lines 4596 to 4602 in a6c8849

	3.6.2.0-p1:
	viTags: []
	viPostInstall: |
	This is a distributor release to fix https://github.com/haskell/security-advisories/blob/main/advisories/hackage/cabal-install/HSEC-2023-0015.md
	The applied downstream patches can be viewed here: https://github.com/hasufell/cabal/tree/cabal-install-v3.6.2.1
	Upstream PR: https://github.com/haskell/cabal/issues/9451
	You can alternatively update to 3.10.2.0 or later.

Patches/fixes to build systems (such as GHC) are not documented properly.

E.g., here are all the GHC bindists where I had to backport the DESTDIR bugfix, because GHC developers don't curate their bindists: https://downloads.haskell.org/~ghcup/unofficial-bindists/ghc/curated/

Answering the above myself: ^ reading the source of config.yaml in ghcup-hs,
it's clear that later entries would win. I.e, in the example above vanilla
would take precedence over main. From config.yaml source:

It is definitely not recommended to enable both vanilla and non-vanilla channels. These are "main channels" so to speak and they are self-consistent (e.g. GHC and HLS versions are ABI compatible). Those invariants potentially go out the window if you mix them.

I advise against using the vanilla channel for regular users. These are not curated and experience has shown that upstream does not invest a lot of time in bindist quality.

[suhail-singh]

Thank you for the detailed response.

It is definitely not recommended to enable both vanilla and non-vanilla
channels. These are "main channels" so to speak and they are self-consistent
(e.g. GHC and HLS versions are ABI compatible). Those invariants potentially
go out the window if you mix them.

Ah! That is a valuable invariant. Thank you for pointing it out.

It might be helpful to explicitly note in the documentation the guarantees (or
aspirational invariances, to be more accurate) that do or don't exist both
within a channel, as well as across channels.

[hasufell]

It might be helpful to explicitly note in the documentation the guarantees

https://hasufell.github.io/posts/2023-11-14-ghcup-is-not-an-installer.html