Modifying version dependencies doesn't appear to work -- but I like it that way.

[creswick]

In hackage 2, you can modify the cabal file "...edit certain bits of package metadata after a release...". Including to change dependencies.

This doesn't appear to work; but I actually think that this is a dangerous feature to enable.

There is significant risk that this will result in non-reproducible builds; particularly when trying to resurrect older software, but also when debugging during new software releases. If a dependency change is made to the cabal file without changing the version (which is specifically disallowed by the current interface) there is no practical way to verify that the software you are building is the same as the software I am building -- we end up in a situation worse than the dependency hell we've all worked to avoid with sandboxing.

Years of experience teach us to look at version numbers, and to trust in the version numbers to represent equality across systems, but this feature violates that ingrained assumption. I can't imagine trying to remotely debug a build failure caused by a difference in the dependency specification of a transitive dependency.

I strongly suggest that the cabal file modifications be restricted to non-semantically relevant fields; fixing documentation typos, source repos, authors, maintainers, etc. things that can not cause cabal to behave differently.

At the moment, this is easily fixed by changing the explanatory text on the 'Edit package metadata...' page, (although it also appears that modifying descriptions is also broken).

[acfoltzer]

+1. If version numbers do not represent equality, we will have to develop a new system in order to guarantee reproducible builds.

[dcoutts]

Indeed it the commit is not working. Will have to investigate that.

On the more general issue, I do understand the concerns. I think a good start to discuss this is if I give a much more detailed explanation, and probably a blog post is a good starting point for that.

[jtdaugherty]

Would it be possible to have that discussion here instead? That way all the relevant details are in one place. I would imagine that if there's a good reason to have this feature then it should be pretty straightforward to summarize the reasons it's important and the reasons why it won't lead to the problems that @creswick outlined.

[dcoutts]

The summary is that other systems (e.g. Gentoo) do this successfully. They do track "revisions", and we're doing the same here (with the x-hackage-revision field for now). They also make these revisions visible in the UI when building so people know in case it's relevant. The issue with reproducible builds I think isn't really valid: right now builds are not reproducible unless you fix the versions of all packages, and if you do freeze the versions then it will work with this scheme too. Builds are not reproducible between different users now for a couple reasons: 1. different snapshots of hackage will lead to different solutions in general, 2. the solution the solver picks will also depend on what the user already has installed.

In summary I think what we want is:

• for revisions to be visible in the UI at least to some degree
• better tools to freeze and reproduce builds

There's room for discussion and design on both points. For example in gentoo you can select which revision to use if you care, though with gentoo revisions can include patches which is not the case for us. On the second point, we have the mechanisms to do this now (local config files), we just need a convenient UI.

[creswick]

Part of what concerns me is that I don't understand what problem this feature is meant to solve; any changes to the cabal metadata will require that clients run a cabal update anyway, so a new version bump should be just fine (to the extent of the PVP). I'm not opposed to allowing these fields to be changed via the web interface, but I do feel strongly that such a change needs to be reflected in the package version number, which the current UI neither allows for nor requires.

With regard to your points:

• Currently, package builds are reproducible if you fix the versions of all packages. This change to hackage invalidates that, and makes it so that the current tools can not produce reproducible builds without a consistent snapshot of hackage; you would have to inspect all cabal packages manually to compare x-hackage-revision fields.
• Furthermore, it is almost always possible to reproduce a build with just the specified dependencies of the immediate package(s) that you are trying to build, if you're using a sandboxed build environment. This occasionally fails due to differences in hackage between 'cabal update' invocations, however, it's trivial to see if that's the case (by comparing the output of ghc-pkg list, or specifically: cabal-dev ghc-pkg list if using cabal-dev). We have ~three years of experience using sandboxes specifically to create reproducible builds, and it works.

One way to resolve this (unless I'm mistaken...) would be to append the x-hackage-version value to the cabal version number.

Another solution (which I'm /much/ less keen on, but it's better than nothing) is to add support for x-hackage-version to ghc-pkg, cabal and cabal-install before providing the ability to make such changes via Hackage. At least then we could use the current set of tools to determine when a build was failing due to a hackage-based metadata change.

[acfoltzer]

It seems to me that some potential changes to package metadata will fall under some criteria addressed by the PVP. Therefore a package version number increase should be required for any such change.

Since this mechanism already does some validation of the changed cabal file, it should enforce a version number increase if any of the rest of the file changes, and I would be quite happy with this solution.

However the scheme of adding x-hackage-version really just takes the existing package versioning system and splits it along two dimensions, adding a great deal of very real tooling headaches without any clear benefit. What we're really talking about are different versions of a package; there's no need to make it more complicated.

[dcoutts]

Currently, package builds are reproducible if you fix the versions of all packages.

Yes.

This change to hackage invalidates that

No, that is not the case. This change does not change the source code for the package you are building, so if you are still using the same package versions then nothing has changed. None of the changes allowed in the .cabal file should leak into the build artefacts.

The only wrinkle here that I'm aware of is that it is possibly to mistakenly over-constrain the dependencies so that a set of versions that did successfully build is now an invalid set of versions. However this is easily detected and fixed, and never leads to building something different, just to not finding a solution. In principle even that could be guarded against as part of a configuration-freeze feature, by picking the exact versions and then overriding/ignoring the package constraints (which is a useful feature independently).

So, to address the main Q: why we want this in the first place, given that it's always possible for the author/maintainer to upload a new version. Yes, that's quite true but in practice, as we all know, it just does not happen. This means that there are many packages that could work, or work together that are just broken. This is unhelpful to new and casual users. The solution is not to force maintainers to be more attentive, or to make them think about the package collection as a whole, but to create a new class of people who see that as their role. There are people doing this job right now, but they do it for the distros. This duplicates work across all the distros and people working direct from hackage cannot benefit from it. Once we see that it is a separate role to think about the health of a set of packages rather than a single package, then it is clear that we cannot use the mechanism of uploading new package versions. The package version is solely the responsibility of the author/maintainer, and distro-maintainers must never fiddle with it. Instead distros need their own extra revision mechanism. For Hackage, we are taking a deliberately conservative approach. In Linux distros, distro packages can and do contain code patches. For hackage I believe that would be a step too far. But we can still gain a lot of the benefits without patching, just by allowing some flexibility with dependency constraints.

The issues about tracking revisions, and reproducible builds are very important. I think the answer again comes from the distros who have made this work in practice for years. They typically do use an extra revision number, distinct from the package's upstream version number. For distros this revision number is even more important than it is for us, since they can include code patches. For us the revision number should I think be somewhat less important, however there are obviously places in our toolchain where it may be important from time to time. I'm happy to discuss the best options here. My several years experience with the Haskell Gentoo packages convinces me that in the end it will really be worth it, that we'll be able to make most packages install out of the box most of the time (or at least get a clearer constraint solver error rather than a build failure).

[dcoutts]

BTW, I'm also open to not fully enabling this feature on hackage until we have some tool changes, if that's the general consensus, or constraining what changes are allowed at first.

[dcoutts]

Furthermore, it is almost always possible to reproduce a build with just the specified dependencies of the immediate package(s) that you are trying to build, if you're using a sandboxed build environment.

This will still be true, in the sense that it is almost true now, and it should in practice almost be true in future.

But this particular point I think is not worth arguing over. Since it is only an "almost" solution, we agree that the right solution is to fix all the versions direct and indirect and to make that convenient. People are working on a cabal-install feature to do that now.

[dcoutts]

One way to resolve this (unless I'm mistaken...) would be to append the x-hackage-version value to the cabal version number.

Yes, that's one reasonable approach. For example, Gentoo uses a scheme like foo-1.0-r2. Then the issue is where would we want this reported, and where would it be accepted as input. We never need it in .cabal files. We could start by merely reporting it in the output of cabal-install's build plan and log output "Building foo-1.0-r2".

[ygale]

There has been significant progress recently on haskell/cabal#1519. Once that feature is implemented, and hopefully also haskell/cabal#949, then I don't see any reason why not to enable editing dependency version constraints.

Even if so, the ability to refer to revision numbers and both here and in cabal would be very valuable.

[dcoutts]

So I'd like to do the minimum possible in Cabal/cabal-install, at least initially, so that we can get this feature rolled out soon. So we could report in cabal install --dry-run and when actually installing packages what revision is being used, but I'd rather avoid (at least initially) providing the ability to specify on the command line which revision to use. That's because the implementation is a lot easier if we don't have to have all the different revisions available in the source index at all times.

[bergmark]

Just to clarify, would this ship with the ability to freeze and ignore constraints then? If so I think it sounds good.

[lpsmith]

dcoutts is exactly correct here; fixing the dependencies and version constraints is neither sufficient nor necessary component of reproducible builds. Reproducible builds (and exactly how reproducible do you want them to be?) is outside the scope of what cabal is currently capable of, and you are going to have to create significant new functionality regardless.

Builds also depend on the package indexes you are compiling against (both installed and what's available), the particular constraint solver you are using, the compiler version you are using, the operating system you are using, any shared objects/dlls your executable depends on, etcetera etcetera etcetera. Freezing the transitive closure of the dependency graph gets you a significant way towards reproducible builds, and would be awesome to have, but you are still going to have to write another system (subsystem of cabal?) to do it.

A version should identify the source code of a package, not its dependencies. You need some other identifier (e.g. a manifest of package versions) to identify a build. And there are significant costs to mandating dependency constraints be immutable.

For starters, I would be far less opposed to putting upper bounds on my package dependencies if I could change them after the fact. From a certain intellectual point of view, it's incorrect to advertise an immutable upper bound because I have no idea if a particular version of my package will work with a future version of your package. And in practice, dependency version constraints tend to be not quite right anyway; it's a lot more convenient to release with dependencies that's approximately correct and then fix it up later.

But by mandating a version bump just to change a dependency means that it's possible to cause other packages to tweak their versions as well. And the version bump tends to cause the binary haskell distributions for various operating system to get recompiled as well, when there is no reason to do if the only thing that has changed is that you advertise modified dependency constraints.