[PATCH 4/6] docs: downloads: Change sources link for libvirt-ocaml

[Andrea Bolognani]

On Tue, Mar 14, 2023 at 11:29:06AM +0100, Peter Krempa wrote:
> On Tue, Mar 14, 2023 at 10:14:33 +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 14, 2023 at 06:12:33AM -0400, Andrea Bolognani wrote:
> > > On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
> > > > The sources for new libvirt-ocaml releases are hosted via gitlab. Add
> > > > the link. Since old releases are not present there preserve also the old
> > > > link.
> > > ...
> > > >    * - OCaml
> > > > -    - `libvirt <https://download.libvirt.org/ocaml/>`__
> > > > +    - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__
> > > > +      `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
> > >
> > > Is the fact that no tarballs have been uploaded for the last few
> > > releases intentional, or an oversight?
> > >
> > > While I see tags for those releases in GitLab, in general git tags
> > > are not a replacement for proper release tarballs, which I'm not
> > > seeing anywhere on GitLab.
> >
> > Indeed, as was seen recently with github, the auto-generated tarballs
> > can change when the backend impl changes, which invalidate any hashes
> > vendors are using to validate tarballs. It is unwise to rely on the
> > auto-generated tarballs as the canonical release artifacts
> >
> > > The Fedora package still points to the libvirt.org server too[1], so
> > > to me it appears that a few uploads were simply missed.
> > >
> > > Rich?
>
> In the following comment:
>
> https://gitlab.com/libvirt/libvirt-ocaml/-/issues/3#note_1292266414
>
> Rich specifically pointed users to the gitlab "release".

Well version 0.6.1.5, which is the latest one available on
libvirt.org, is PGP signed by Rich himself, so at some point in the
past we clearly got this to work :)

Could he have lost his access or something?

-- 
Andrea Bolognani / Red Hat / Virtualization