package revisionism can break things

[toolslive]

Sometimes, a package is patched after a release, and then it's released again, with the same version.

This practice makes it hard to track dependency changes, but it also (probably) changes the checksums of the modules in the package. As a consequence, this can break the usage of this module in a dynamically loadable plugin context. It has happened quite a few times for us, and I think it's just as easy to just release a new version whenever the code changed.

As a concrete example,
the recent patching of oUnit.2.0.0 causes a

   Dynlink.Error "interface mismatch on OUnitConf"

[hannesm]

I'd be very much in favour if you add custom patches to a released package, bump its version (a lengthy discussion is #10350 (comment)). there's no harm in having foo-1.0-1 etc. around, and makes it obvious which package is actually installed. if the source checksum of a package changes while that package is released to opam-repository, there shoud as well be a version bump (at least a -n suffix, and the old version may need to be removed).

if the maintainers of opam-repository agree with this ("no patches / modification of released packages"), it should be communicated in CONTRIBUTING.md. It would make this opam repository more immutable (easier to debug issues). the downside is that upon a new version opam recompiles all reverse dependencies - but imho this is required (as @toolslive outlined above).

[hcarty]

I ran into something similar today - I tried to opam update -u which triggered a rebuild of effectively everything due to a change to ocamlfind 1.7.3 (the version I already have/had installed). The result left my switch in a broken state, with Lwt unable to build for example.

The fix was to install a fresh switch, but in this case the error message was not very helpful, saying that Lwt's configuration script could not build a basic toplevel.

[dbuenzli]

if the maintainers of opam-repository agree with this ("no patches / modification of released packages"), it should be communicated in CONTRIBUTING.md. It would make this opam repository more immutable (easier to debug issues). the downside is that upon a new version opam recompiles all reverse dependencies - but imho this is required (as @toolslive outlined above).

@hannesm To move on this issue I would suggest you prepare a PR that does communicates the rules and a scheme in CONTRIBUTING.md.

One of the problem I see is that there's no way to make sure that the new name allows to fit existing constraints on the package in other packages. This means that all the other packages constraints have to be updated and that upstream needs to be aware of this new version name (for e.g. when it opam submits). In some sense you would like a new version number vn that sorts against the old one vo as vo < vn but such that for all v : vo < v implies vn < v. But maybe I'm missing something w.r.t. how version ordering works.

[pmetzger]

MacPorts has a notion of a revision number for all packages. Packages start (naturally) at revision number 0. If you make any substantive change to a package (altering dependencies, patches, anything else), you bump the rev number. When the package gets upgraded to the next maintainer release, you put the rev number back to 0 again. For simplicity, the revision field is assumed to be 0 if it isn't listed in the Portfile, so in the usual case (in which nothing gets changed between maintainer releases), you don't have to edit anything at all.

[toolslive]

b610e6d
broke our builds.

[kit-ty-kate]

@toolslive could you please give more information ?

[domsj]

@kit-ty-kate the linked commit breaks the build for users that specify snappy.0.1.0 that use an ocaml-version >= 4.06 (with unsafe-string option enabled), so we had to adapt...

[samoht]

Are we talking here about modifying the package contents or the package metadata?

I don't think modifying the package contents without doing a new release has been done (or maybe it was just to fix a broken release of a package in the process of being published to opam). And I agree that we shouldn't change the contents of a package after it is released.

However, changing the metadata (e.g. the version constraints, the available platform, etc) is what the repository maintainers have to do to maintain a proper repository hygiene. Initial constraints are usually not very well defined, and it's the job of the the repo maintainers to help upstream to make them as exact as possible, to adapt to new compiler versions, etc. It's very hard to be deal with forward compatibility in general (and I know no perfect solution for this, but allowing human intervention once a breakage is observed by the CI and/or reported by an user).

[dbuenzli]

@samoht I think the problem is when people patch packages without bumping the version number. That happens at the metadata level but formally that changes the package contents so a version bump should happen in that case.

[hannesm]

yes, this is about changing checksums of release tarballs (where the contents changed), adding patches to the package (fix compilation on YYY), and other things that affect the build results. (see e.g. the above linked issue, or nocrypto 0.5.4-1 / -2 as "good examples" how to integrate patches if upstream is not responsive). changing constraints on dependencies is (usually) nothing that leads to a different build result.

[toolslive]

Are we talking here about modifying the package contents or the package metadata?

The original issue report gives a concrete example of a patch of the contents of the oUnit package.
Also, we've seen changes to the metadata that break things as well: typically adding an upper version limit dependency that no longer allows to install a certain version of a package which was previously installable.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove the stale label, or comment, or this will be closed in 15 days.

[kit-ty-kate]

this should not have been closed

[github-actions]

This issue has been open 90 days with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. If you come across this issue in the future, you may also find it helpful to visit our forum at https://discuss.ocaml.org where queries related to OCaml package management are very welcome.

[AltGr]

This should probably be in the FAQ, and not directly related, but there is a trick if you need a stable (in time) repository and changes are breaking things for you like making packages uninstallable: you can pin the git revision of the repository you want to use to a given hash:

opam repo add known_good_repo git+https://githuib.com/ocaml/opam-repository#HASH

Then set your switch to use known_good_repo instead of default, either with opam repo set-repos known_good_repo on the current switch, or with opam switch create --repos=known_good_repo.

[pmetzger]

FWIW, I'm still in favor of revision (and epoch!) numbers...