Outdated bounds on hslogger?!

I just had a little dependency issue with hslogger:

[__3] rejecting: hslogger-1.3.1.0 (conflict:
base==4.14.3.0/installed-4.14.3.0, hslogger => base>=4.3 && <4.14)

The weird thing is that this bound is outdated since 2020-04-09, when a first revision was made to this hslogger version:

https://hackage.haskell.org/package/hslogger-1.3.1.0/revisions/

Why doesn't head.hackage simply serve the latest revisions?

This is a long-standing issue with head.hackage. See https://github.com/hvr/head.hackage/issues/65 for an issue that was filed against the project back when it lived on GitHub. (It looks like that issue was never migrated to GitLab, for better or worse.)

If I understand the comments here correctly, Hackage overlays fundamentally work over the original (i.e., revision-less) packages, and any revisions thereafter must be manually applied. There was a suggestion here to provide scripting to make this process slightly easier, but as far as I can tell, that hasn't been done yet.

For your immediate problem involving hslogger, the simplest fix would be to amend the hslogger patch to include the revisions in its .cabal file.

Thanks for the explanation, Ryan! :)

As a workaround, I have simply used --allow-newer so far, which is slightly tedious but not too bad.

If I understand the comments here correctly, Hackage overlays fundamentally work over the original (i.e., revision-less) packages, and any revisions thereafter must be manually applied.

Where does the logic for these overlays live? E.g. where's the logic that combines the patches from this repository with the "pristine" packages from upstream Hackage? It seems to me that it should be possible to include Hackage revisions in this process.

Where does the logic for these overlays live? E.g. where's the logic that combines the patches from this repository with the "pristine" packages from upstream Hackage?

@bgamari is far more qualified to answer this question than I am, but my understanding is that the code for the overlay itself is largely contained in https://github.com/bgamari/hackage-overlay-repo-tool. I'm unclear which part governs the use of --pristine specifically.

Including hackage revisions means that patches can become conflicted by people updating the revision for a package. It seems better to me to keep the requirement for the patch to apply to the pristine version.

mentioned in merge request !186 (merged)

I've submitted !186 (merged) to include hslogger's revisions in its head.hackage patch.

closed with merge request !186 (merged)

closed with commit 36f827db

mentioned in commit 0455656e

mentioned in commit 36f827db

Thanks for the fix, @RyanGlScott! :)

I still feel that copying each relevant Hackage revision explicitly isn't very ergonomic. I think it should be possible to track the index-state of hackage.haskell.org and apply patches relative to the revisions at that index state.

Since I use head.hackage rather infrequently, I'm not very affected by this issue anyway.