>> Indeed -- GitHub does seem to repack archives with different distribution >> checksums, quite probably when they change their. > > I was not aware of this -- I assumed archives were built deterministically. > > Do you know how often that happens? Is it ok for maintainers to rely > on those release archives, if they are ready to update the checksum > whenever it changes? Or is that inherently unstable and should we add > an "opam lint" rule to warn about these URLs? > > I use this for the ocamlbuild package, because it is extremely > convenient. I don't have another static hosting page than the github > repo right now (not even a .github.io page), and I would rather avoid > it if reasonable.
GH archives are in practice stable. Bitbucket ones seem to be re-generated regularly. Thomas > > On Mon, Feb 22, 2016 at 10:59 AM, Anil Madhavapeddy <a...@recoil.org> wrote: >> On 22 Feb 2016, at 15:41, David Allsopp <dra-n...@metastack.com> wrote: >>> >>> No they would not – getting people on the conversation thread of a PR is >>> vastly superior; it groups the information and discussion in the place >>> where it’s merged and archives it there. I have certainly had to bisect >>> opam-repository before, so being able to go from a >>> SHA1->Merge->PR->Conversation is very useful. >> >> I'm in complete agreement with David here. We already have an established >> process for submitting a PR, and I'd strongly prefer that we do not create >> another out-of-band mechanism (email) to contact people. Why not just >> create an issue in opam-repository and assign to the submitter, for instance? >> >> Fabrice: I think in the short term, not CCing opam-devel for such e-mails >> would be appreciated. I tend to just e-mail people directly if they really >> don't respond. >> >>> On this string of PRs, I’m wondering if you’re treating the symptom, and >>> not the cause. Each PR so far is to do with an altered checksum from a code >>> service’s binary release system which suggests that they’re not canonical >>> (i.e. that they’ve changed the zip in what should be a trivial manner – >>> e.g. putting the files in a different order). Rather than fixing the >>> checksums, and causing this to happen again at the whim of a zip library, >>> would it not be better to put in place a policy that zip links should not >>> be to GitHub/BitBucket/Whatever auto-generating URLs but to actual static >>> files (e.g. on github.io)? >> >> Indeed -- GitHub does seem to repack archives with different distribution >> checksums, quite probably when they change their. >> >> On the broader question that Fabrice raises about access rights to >> individual packages, it's probably worth bisecting the contributors and why >> packages need to be affected: >> >> - individual package maintainers: submit a single package, and tend not to >> get regular updates about its health, for instance when a related package is >> upgraded. We do need a mechanism to update a maintainer about when a >> package is broken by an unrelated change. Right now, if this happens we add >> an upper bound constraint, but this doesn't remind the package maintainer to >> release a version compatible with the new related package. >> >> - distribution porters: adding depexts to a lot of packages (I've just >> rolled through and added Alpine and Fedora for instance), or minor patches >> hidden behind an `os` constraint. For this work, blocking on 10-20 package >> maintainers would be very onerous and hold back the health of the repository >> for that work. >> >> - architecture porters: often have a number of short-term fixes for (e.g.) >> ARM, and these are placed behind patch constraints so that for an x86 user, >> the OPAM experience is unmodified. These then need to be rolled upstream. >> >> I'm struggling a little to see what the specific problem that Fabrice is >> raising is, which appears to be the desire to "lock" a package against >> commits until he approves it. This is a reasonable request and should be as >> simple as the current active repository maintainers not merging requests >> that touch OCamlPro packages until approved by Fabrice (and/or other >> OCamlPro staff?). If this results in a hanging PR (as has happened in the >> past with ocp-build errors due to a lack of resources upstream to maintain >> it), then we need to just take an executive decision and either commit it or >> close the PR. >> >> I don't see anyone else who wants this: I am quite happy for people doing >> bulk builds to generate and improve constraints against my packages. More >> generally, lightweight tooling to make it easier to enforce such constraints >> locally would be very useful -- for instance, something to probe for >> disparities in source archives and the `opam` metadata in the repository and >> alert for inconsistencies. >> >> regards, >> Anil >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
