[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libreoffice-website] Fixing broken links for previous LibreOffice releases
- Subject: [libreoffice-website] Fixing broken links for previous LibreOffice releases
- From: William Gathoye <firstname.lastname@example.org>
- Date: Thu, 21 Mar 2019 15:22:20 +0100
- To: email@example.com
Like some of you know, I'm also working on some packages for the
Chocolatey community (the package manager for Windows). LibreOffice is
one of the package I maintain there.
I just wanted to know whether TDF would be open to make a redirection rule
* from https://download.documentfoundation.org/libreoffice/stable/
* to https://downloadarchive.documentfoundation.org/libreoffice/old/
* *for files that are not found at*
https://download.documentfoundation.org/libreoffice/stable/ (see it
like a try_files in terms of NGINX)
Since the switch to the Fresh/Still branch, I have been facing a few
issues with my LibreOffice packages. I tried to fix them, but the
Chocolatey staff asked me to try to fix the issue upstream instead.
At Chocolatey the links to the LibreOffice Windows installers break when
the following use cases occur:
* each time a LibreOffice branch becomes deprecated/renamed: e.g. when
the fresh 6.1 became the still 6.1
* each time a new version is released: e.g. 6.1.5 is released, 6.1.4
is thus moved away from download.documentfoundation to
downloadarchive.documentfoundation. Happened today with 6.2.0 being
moved away since 6.2.2 has been just released.
In these cases, our LibreOffice Chocolatey packages become pointless
because previous versions cannot be installed by Chocolatey users.
_Why not fix the issue from Chocolatey?_
* A Chocolatey package that has been published as a specific version
cannot be republished again except if we suffix the version by the
current date. This is annoying because if a user wants to install
LibreOffice 6.1.4 for example, this won't work because the version
will need to be suffixed and I'll need to know that suffix in
advance e.g. 18.104.22.16890321.
* Republishing all packages will trigger all the chocolatey unit tests
against each package that has been updated. The Chocolatey CI queue
will run for a very long time and will defer the queue for other
packages as well. Packages could be republished in series rather
than everything at once though.
* Chocolatey has the ability to bundle installers inside the packages,
why not use this feature? We are reaching the CDN limit here.
Packages above 200Mio cannot be cached via our Cloudflare CDN. Plus,
this will increase Chocolatey's storage costs.
_Why bother with old versions?_
This is the same question as why TDF is still keeping old binaries. Plus
the fact, speaking as a LibreOffice contributor, this is sometimes
easier to try to reproduce a Windows specific bug using chocolatey
rather than downloading each LibreOffice installer manually (even if I
know TDF is providing bibisect versions).
Thanks in advance for your help,
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
|Re: [libreoffice-website] Fixing broken links for previous LibreOffice releases||Guilhem Moulin <email@example.com>|
- Prev by Date: Re: [libreoffice-website] Minutes from the Tue Mar 19 infra call
- Next by Date: Re: [libreoffice-website] Fixing broken links for previous LibreOffice releases
- Previous by thread: [libreoffice-website] Minutes from the Tue Mar 19 infra call
- Next by thread: Re: [libreoffice-website] Fixing broken links for previous LibreOffice releases