No bootstrap files in Hackage cabal-install tar ball

[blackgnezdo]

Describe the bug

cabal-install-3.4.0.0.tar.gz as distributed on hackage doesn't include bootstrap directory.

These files are very useful when bootstrapping cabal-install without having a previous version handy, e.g. in my OpenBSD port. I was previously using an rc-tagged bundle on github and hoping to change the dependency to Hackage instead.

Expected behavior

Enough files available on Hackage to build all of cabal-install.

System information

• OpenBSD
• cabal-3.4.0.0, ghc-8.10.3

[chenrui333]

Just to echo here, the bootstrap.py file is not part of the cabal-install-3.4.0.0.tar.gz

[arrowd]

Bumped into this problem too when updating FreeBSD port of cabal-install. Can we get the script back?

[ciez]

@arrowd
looks like bootstrap.sh is gone for good.

See #6701 and #6719

[ambs]

Probably rewrite README.md, then?

[fgaz]

@ambs what's wrong with the readme?

[ambs]

README.md refers to the bootstrap.sh file. If it is not shipped, we should not refer to it :)

[fgaz]

@ambs could you link to the specific line where we mention bootstrap.sh? I can't find it

[ambs]

Probably we are referring to different things but look into https://hackage.haskell.org/package/cabal-install. Line 53.

[fgaz]

Indeed we are! The readme is fixed on master. Changing the one on hackage would require a release

[ambs]

Yeah, common mortals prefer to use releases. :-)
Also, it looks like the version in master suggests a folder named bootstrap (?), which doesn't exist in the released tarball as well.
So probably we are really needing a release!
Or will the bootstrap folder be only available in the git?
Probably clarifying would make sense. I will use the git version, nevertheless. Thanks!

[ambs]

And extra detail, bootstrap-deps.json seems to be missing from the master tree?

[gbaz]

What remains to be done to resolve this?

[arrowd]

The bootstrap script should be distributed with Hackage tarball.

[Mikolaj]

The bootstrap script should be distributed with Hackage tarball.

I can do that for 3.8.1 release. Do you mean the bootstrap/bootstrap.py script? In which of the 4 packages shiould it be included? Would that be enough to close this ticket?

[arrowd]

Do you mean the bootstrap/bootstrap.py script?

Yes.

In which of the 4 packages shiould it be included?

The cabal-install one.

[Mikolaj]

Thank you.

Uhoh:

~/r/cabal/cabal-install$ cabal check
Warning: The following warnings are likely to affect your build negatively:
Warning: 'extra-source-files: ../bootstrap/bootstrap.py' is a relative path
outside of the source tree. This will not work when generating a tarball with
'sdist'.
Warning: The following errors will cause portability problems on other
environments:
Warning: 'extra-source-files: ../bootstrap/bootstrap.py' is not a good
relative path: "parent directory segment: .."
Warning: Hackage would reject this package.

Cheat via a symbolic link? Move bootstrap/ from top level of the repo into cabal-install/?

[Mikolaj]

And extra detail, bootstrap-deps.json seems to be missing from the master tree?

These files are now named bootstrap/linux-8.10.7.json, etc.

[Mikolaj]

To clarify, the bootstrap/bootstrap.py script is useless without one of the GHC version specific files, such as bootstrap/linux-8.6.5.json. Does it mean we should ship those files as well or is the script alone useful to somebody? If we are to ship those extra files, that would mean some more links. Perhaps the simplicity of keeping everything in the top-level bootstrap directory, which is advertised in the soon-to-be-released version of README, and not linking to it (and updating the links in the repo and in .cabal file) from other directories and packages, is worth preserving?

Would that be acceptable?

[arrowd]

That's right, *.json files are also required.

[blackgnezdo]

FWIW, OpenBSD port packages its own openbsd.json. It's easy enough to regenerate and keep around. Hence from my point of view bootstrap.py is enough. Then again, I switched to grabbing a tagged version straight off github even if this is not exactly a release.

[arrowd]

FWIW, OpenBSD port packages its own openbsd.json. It's easy enough to regenerate and keep around. Hence from my point of view bootstrap.py is enough. Then again, I switched to grabbing a tagged version straight off github even if this is not exactly a release.

Well, yes. We at FreeBSD patch the existing .json, but it is indeed easier to provide our own, because shipped .json files are usual out of date and lacking behind GHC releases.

[Mikolaj]

[Edit: the below is now fixed]:
BTW, let me turn your attention to #8166. Something has broken with the creation of bootstrap files (let's hope, something trivial). So we are going to be stuck with the old bootstrap files until this is fixed.

[Mikolaj]

Hi there! In the heat of the battle, this request has been ignored and then re-assigned to the upcoming release 3.12.

Is bundling bootstrap.py inside the Hackage package cabal-install (and symlinking to it from the bootstrap/ directory), but not bundling the .json files, still useful for anybody? IMHO, if your scripts get it from the repo, that may be the safest option. I don't even know if symlinks work on Windows. It would be unfortunate if you updated your scripts to get bootstrap.py from Hackage and then we had to revert the location back to bootstrap/ due to a random fallout.

[ulysses4ever]

I don't see a reason to prefer Hackage to GitHub for getting these script and JSON files. And the change is prone to all sorts of dangers as Mikolaj points out above.

Also, priority: high is not adequate imo.

[blackgnezdo]

Considering how long this went unpatched I can't justify this being a high priority item. A reason to prefer the official hackage release is just that: it's official. My guessing at the right tag and relying on github to package up the bundle is somewhat less reliable. It's somewhat ironic, that the key GitHub used to sign the latest release is GPG key ID: 4AEE18F83AFDEB23
Expired