Hi again,
I only saw your reply now somehow though I thought I had checked
sometimes...
On Wed, 10 Jun 2020 at 04:39, hekkaidekapus <cireyapmin(a)gmail.com> wrote:
Thanks for taking time to reply. I do not know people around here, I
assume
this helpful Tristan is the same as the one in the SIG’s meeting logs
dated to
June 9, 2020 (UTC); anyway, thank you Tristan very much.
That's right
> So err, why not use the modules?
You can `dnf module install ghc:8.10` today in Fedora to install the latest
ghc,
but then you lose access to all the prebuilt Haskell libraries, it's true.
> I am tracking Stackage LTS releases.
> Fedora 32 is based on LTS 14 […]
Now, I understand how the decision about which packages and which versions
to
ship is made.
Okay, yes, I just updated Rawhide to ghc-8.8.4 last week for F33.
I am suggesting to untie the release of GHC packages from other packages’,
as
long as the latter are not in the “boot” set[^1]. Id est, if upstream
releases
GHC version λ, my inquiry is about whether Fedora could release ghc-λ
regardless of which Stackage snapshots are based on ghc-λ.
You mean to use newer ghc than Stackage LTS, I see - I think that is not
generally possible.
Though it might work sometimes perhaps. ((8.8.4 is newer than current LTS
16 though.))
Typically we see considerable breakage in Stackage Nightly when moving to a
new ghc major version.
Mostly this is due to API or other major changes in ghc's libraries: eg
good recent example is MonadFail.
eg
https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/8.8
https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/8.10
Such a suggestion might be nonsense in face of how packaging is done
in
Fedora, so please correct me if I am way off on the technical side.
Currently,
my understanding is that the state of affairs is as it is because
Every major version release of ghc generally has some breaking changes.
I think shipping a ghc incompatible with the Stackage version will cause
problems
both for packaging and users.
* it is a great __convenience__ to have a source of assurance
(Stackage)
that
hundreds of upstream packages will build successfully;
* most of those packages are taken care of in Fedora by a single person
(Jens)
who, by the way, is an upstream Stackager, thus relying on Stackage is
“natural”.
To be clear, may the above be close to the reality, I do not object
against
any of it: people who put in the work make the choices in FOS.
As of why should I bother using the latest upstream GHC, the answer is the
same as the reason I use Fedora in the first place: I want “bleeding-edge”
yet
solid software without _Gentoo-ing_ everything.
I know this is popular having the latest and greatest ghc,
but with the breaking changes we see it is really quite impractical I think.
I have happily been using 8.6.5 (LTS 13-14) for many months without any
problems.
And just switch recently to developing with LTS 15: basically I prefer to
stay
one LTS release behind because I prefer just to use the last final minor
release: eg LTS 15.16.
I imagine that most users honestly would not notice the differences much,
unless
they want to play with the latest fancy "typery" or benchmarking perhaps.
Sure if Fedora was still on 8.4 or 8.2 say that would be an increasing
major concern,
but as long as we are incrementing Haskell versions even if a release behind
I feel it is not a huge issue, and modules (and stack) are there for those
that really
must have the latest ghc. But I am taking the general feedback from the
community
into account (even Stackage has had complaints about being too slow to move
ahead).
This time I was slightly more aggressive and went with newer minor ghc than
in Stackage
and latest LTS 16 which is still evolving rather than packaging the final
LTS 15.
So why don’t I switch to
modularity streams? Parallel installs and partial upgrades is not my
use
case;
I upgrade the whole distribution at once.
Modules are not parallel installs. Did you try it out?
Upgrades of modules between releases is also generally supported.
Eg you can update ghc:8.8 or ghc:8.10 from F31 to F32 to F33: it should
just work.
It may be the case that properly doing something along the lines of
my
suggestion would lead to mimicking what is done in Fedora Rust or Fedora
Go, I
am unclear on the details. Is it so? For instance, the GCC maintainers
upgrade
it independently of the release schedule of, say Boost[^2].
AIUI Fedora Rust basically only ships library sources as cargo cache src
files and builds them per executable.
Maybe we could fool cabal-install to use source tarballs instead, but I
don't find this approach attractive.
Rather my vision is that people should use cabal-rpm to build Haskell
projects on Fedora on top of our binary libraries.
Well I hope that helps a little - it is difficult to make everyone happy.
If we had "infinite resources" we could have modules for each major LTS
release, etc.
Maybe one day with greater automation, but we are just not there yet.
Thanks, Jens