mhx / dwarfs

A fast high compression read-only file system for Linux, Windows and macOS
GNU General Public License v3.0
2.16k stars 58 forks source link

dwarfs is difficult to build without the git repository (when not using the source tarball) #155

Closed tpwrules closed 1 year ago

tpwrules commented 1 year ago

When building dwarfs for nixpkgs, the build is not allowed access to the git metadata to improve reproducibility. We also generally prefer to build directly from git instead of a released source archive (which does already have the necessary files). This means that the git tag/version/etc cannot be read out of the repository to generate those files and the build fails. We work around this by patching the cmake files and defining some cmake variables instead, but this is clunky.

It would be really handy to support some sort of DWARFS_VERSION_OVERRIDE cmake variable which just took e.g. "v0.7.1" and substituted default values for the other version parameters and wrote out the appropriate files. We do not usually provide a commit hash in the build either, just the git tag.

mhx commented 1 year ago

I'd rather not go down that route as it will eventually result in the override not getting updated and thus binaries will be produced reporting a wrong version number.

It should be easy to build without the git repo if you use the source tarball. If you say you "prefer" to build from the git repo, it sounds like you could actually build from the tarball?

tpwrules commented 1 year ago

We already have infrastructure to automatically splice the version number into the git tag and the source code, so there is no risk of the override not getting updated in our scenario. You can see that here if you are curious: https://github.com/NixOS/nixpkgs/blob/b02fd49f1638f7241843aa5a4fe73d8bc9bf1599/pkgs/tools/filesystems/dwarfs/default.nix#L27 .

Yes, theoretically it's possible to use the source tarball. I have not tried, but I have checked it does have the relevant version files. But when the source tarball is not simply a tar of the related git hash and has ancillary files like this, it harms reproducibility which is why we prefer not to do it.

mhx commented 1 year ago

I'm worrying less about nix, more about others misusing the option.

I'll think about it.

mhx commented 1 year ago

Can you check if mhx/nixpkgs-version-override works for you? I've tested this locally with something like:

cmake .. -DWITH_TESTS=1 -DNIXPKGS_DWARFS_VERSION_OVERRIDE=v0.8.0 -GNinja
mhx commented 1 year ago

Don't test this yet, I should have waited for the CI pipeline to finish... ;)

mhx commented 1 year ago

Okay, this looks better.

tpwrules commented 1 year ago

Is there a reason to call this nixpkgs-specific? Is that a defense against misuse in your mind?

mhx commented 1 year ago

Is there a reason to call this nixpkgs-specific? Is that a defense against misuse in your mind?

It's both to document where the feature originated from and to discourage its use outside of nixpkgs. I still think it's a rather obscure use case. :)

mhx commented 1 year ago

Did you get a chance to test the code?

tpwrules commented 1 year ago

Yes, it seems to work properly. Thank you.

mhx commented 1 year ago

Thanks, merged into main.