| Message ID | 20240923122128.14126-1-ngraves@ngraves.fr |
|---|---|
| Headers | show |
| Series | Update libreoffice to its latest version. | expand |
Am Montag, dem 23.09.2024 um 14:15 +0200 schrieb Nicolas Graves: > This patch series updates libreoffice to its latest version. I used > local builds of derivations with ccache > (https://issues.guix.gnu.org/68315) to test developping and updating > a big package incrementally. Some commits can be squashed, but I > think we should at least keep separate 24.2.0.3, 24.2.6.2, 24.8.1.2. > It also adds an updater for the libreoffice package. Why those steps? Should we perhaps have multiple packages with some older versions for the time being? > Nicolas Graves (10): > import: Add %libreoffice-updater. LGTM > gnu: libreoffice: Update to 24.2.0.3. > gnu: libreoffice: Update to 24.2.1.2. > gnu: libreoffice: Update to 24.2.2.2. > gnu: libreoffice: Update to 24.2.3.2. > gnu: libreoffice: Update to 24.2.4.2. > gnu: libreoffice: Update to 24.2.5.2. > gnu: libreoffice: Update to 24.2.6.2. > gnu: libreoffice: Update to 24.8.1.2. > gnu: hunspell-dictionaries: Update to 24.8.1.2. As noted in the comment hunspell and libreoffice ought to be kept in sync. IIUC, this would mean updating hunspell-dictionaries in lockstep with libreoffice on those intermediate steps as well, no? Cheers
On 2024-09-23 20:35, Liliana Marie Prikler wrote: > Am Montag, dem 23.09.2024 um 14:15 +0200 schrieb Nicolas Graves: >> This patch series updates libreoffice to its latest version. I used >> local builds of derivations with ccache >> (https://issues.guix.gnu.org/68315) to test developping and updating >> a big package incrementally. Some commits can be squashed, but I >> think we should at least keep separate 24.2.0.3, 24.2.6.2, 24.8.1.2. >> It also adds an updater for the libreoffice package. > Why those steps? Should we perhaps have multiple packages with some > older versions for the time being? 24.2.0.3 is a big update which adds packages and substitutions, I think it's good to keep those changes in one commit. On the libreoffice website, they have only two libreoffice downloads: https://www.libreoffice.org/download/download-libreoffice 24.8.1.2 is the current stable release 24.2.6.2 is the previous stable release (~= LTS) I don't see libreoffice bringing tremendous changes from version to version, I'm not sure having two versions is necessary. That said, it is very doable to have two with a -lts version. > >> Nicolas Graves (10): >> import: Add %libreoffice-updater. > LGTM >> gnu: libreoffice: Update to 24.2.0.3. >> gnu: libreoffice: Update to 24.2.1.2. >> gnu: libreoffice: Update to 24.2.2.2. >> gnu: libreoffice: Update to 24.2.3.2. >> gnu: libreoffice: Update to 24.2.4.2. >> gnu: libreoffice: Update to 24.2.5.2. >> gnu: libreoffice: Update to 24.2.6.2. >> gnu: libreoffice: Update to 24.8.1.2. >> gnu: hunspell-dictionaries: Update to 24.8.1.2. > As noted in the comment hunspell and libreoffice ought to be kept in > sync. IIUC, this would mean updating hunspell-dictionaries in lockstep > with libreoffice on those intermediate steps as well, no? I haven't delved that deep in this but I think it's not necessary. The reason is that they are mostly dictionaries whose updates are uncorrelated to what's happenning in libreoffice itself but rather edge cases in languages. They are unlikely to break user experience, plus it will be for only a few commits. At the end of the series seems fine to me.
Am Dienstag, dem 24.09.2024 um 16:29 +0200 schrieb Nicolas Graves: > On 2024-09-23 20:35, Liliana Marie Prikler wrote: > > > Am Montag, dem 23.09.2024 um 14:15 +0200 schrieb Nicolas Graves: > > > This patch series updates libreoffice to its latest version. I > > > used > > > local builds of derivations with ccache > > > (https://issues.guix.gnu.org/68315) to test developping and > > > updating > > > a big package incrementally. Some commits can be squashed, but I > > > think we should at least keep separate 24.2.0.3, 24.2.6.2, > > > 24.8.1.2. > > > It also adds an updater for the libreoffice package. > > Why those steps? Should we perhaps have multiple packages with > > some older versions for the time being? > > 24.2.0.3 is a big update which adds packages and substitutions, I > think it's good to keep those changes in one commit. Fair enough. > On the libreoffice website, they have only two libreoffice downloads: > https://www.libreoffice.org/download/download-libreoffice > > 24.8.1.2 is the current stable release > 24.2.6.2 is the previous stable release (~= LTS) > > I don't see libreoffice bringing tremendous changes from version to > version, I'm not sure having two versions is necessary. > > That said, it is very doable to have two with a -lts version. I agree, having an LTS is probably enough. So can we cut this short by keeping the separate ones you mention and also keep 24.2.6.2 as the LTS? > > > > > Nicolas Graves (10): > > > import: Add %libreoffice-updater. > > LGTM > > > gnu: libreoffice: Update to 24.2.0.3. > > > gnu: libreoffice: Update to 24.2.1.2. > > > gnu: libreoffice: Update to 24.2.2.2. > > > gnu: libreoffice: Update to 24.2.3.2. > > > gnu: libreoffice: Update to 24.2.4.2. > > > gnu: libreoffice: Update to 24.2.5.2. > > > gnu: libreoffice: Update to 24.2.6.2. > > > gnu: libreoffice: Update to 24.8.1.2. > > > gnu: hunspell-dictionaries: Update to 24.8.1.2. > > As noted in the comment hunspell and libreoffice ought to be kept > > in sync. IIUC, this would mean updating hunspell-dictionaries in > > lockstep with libreoffice on those intermediate steps as well, no? > > I haven't delved that deep in this but I think it's not necessary. > The reason is that they are mostly dictionaries whose updates are > uncorrelated to what's happenning in libreoffice itself but rather > edge cases in languages. They are unlikely to break user experience, > plus it will be for only a few commits. At the end of the series > seems fine to me. Fair enough. Cheers
On 2024-09-24 19:03, Liliana Marie Prikler wrote: >> That said, it is very doable to have two with a -lts version. > I agree, having an LTS is probably enough. So can we cut this short by > keeping the separate ones you mention and also keep 24.2.6.2 as the > LTS? Done in a v2, but I'm not actually sure it's a great solution. The issue is that the "LTS" is supported for 8 months (february to november 2024 for 24.2). That means we have an overlap of main and lts versions for only 2 months, and then libreoffice probably recommends only the 24.8 stable release (from memory, the page had a single release a few months prior, or we can wait and see until november). Keeping it in Guix would label -lts something that is not supported by upstream 2/3rd of a year. I only see two relevant solutions: - following the latest stable release (which is stable, it's not a beta, there is a prerelease version currently at 24.8.2) - wait with 24.2 until november and then switch to 24.8
Am Mittwoch, dem 25.09.2024 um 09:52 +0200 schrieb Nicolas Graves: > On 2024-09-24 19:03, Liliana Marie Prikler wrote: > > > > That said, it is very doable to have two with a -lts version. > > I agree, having an LTS is probably enough. So can we cut this > > short by keeping the separate ones you mention and also keep > > 24.2.6.2 as the LTS? > > Done in a v2, but I'm not actually sure it's a great solution. The > issue is that the "LTS" is supported for 8 months (february to > november 2024 for 24.2). That means we have an overlap of main and > lts versions for only 2 months, and then libreoffice probably > recommends only the 24.8 stable release (from memory, the page had a > single release a few months prior, or we can wait and see until > november). > > Keeping it in Guix would label -lts something that is not supported > by upstream 2/3rd of a year. > > I only see two relevant solutions: > - following the latest stable release (which is stable, it's not a > beta, there is a prerelease version currently at 24.8.2) > - wait with 24.2 until november and then switch to 24.8 I think we should strive to be as up-to-date as possible, but I see no harm with keeping a 24.2 version until November. WDYT?
Nicolas Graves via Guix-patches via <guix-patches@gnu.org> writes: > On 2024-09-24 19:03, Liliana Marie Prikler wrote: > >>> That said, it is very doable to have two with a -lts version. >> I agree, having an LTS is probably enough. So can we cut this short by >> keeping the separate ones you mention and also keep 24.2.6.2 as the >> LTS? > > Done in a v2, but I'm not actually sure it's a great solution. The issue > is that the "LTS" is supported for 8 months (february to november 2024 > for 24.2). That means we have an overlap of main and lts versions for > only 2 months, and then libreoffice probably recommends only the 24.8 > stable release (from memory, the page had a single release a few months > prior, or we can wait and see until november). > > Keeping it in Guix would label -lts something that is not supported by > upstream 2/3rd of a year. > > I only see two relevant solutions: > - following the latest stable release (which is stable, it's not a beta, > there is a prerelease version currently at 24.8.2) > - wait with 24.2 until november and then switch to 24.8 Maybe worth considering: Debian tracks 24.8 including backporting it to stable. ArchLinux and Homebrew ships 24.8 (although homebrew also provides 24.2). So it looks like latest libreoffice stable release is packaged often. Thanks for working on an upgrade, regardless of if it becomes 24.2 or 24.8 -- I'm happily using 7.6.7.2 via Guix on Trisquel to get something more recent than aramo's 7.3.7. /Simon
On 2024-10-14 15:31, Simon Josefsson via Guix-patches via wrote: > Nicolas Graves via Guix-patches via <guix-patches@gnu.org> writes: > >> On 2024-09-24 19:03, Liliana Marie Prikler wrote: >> > > Maybe worth considering: Debian tracks 24.8 including backporting it to > stable. ArchLinux and Homebrew ships 24.8 (although homebrew also > provides 24.2). So it looks like latest libreoffice stable release is > packaged often. > > Thanks for working on an upgrade, regardless of if it becomes 24.2 or > 24.8 -- I'm happily using 7.6.7.2 via Guix on Trisquel to get something > more recent than aramo's 7.3.7. Hi Simon, I'll have to submit a v3 to remove glibc from inputs (which was a mistake), and will probably rebase this version on 68150 and block the issue by that. Since this will probably take more than 2 weeks to get merged, I'll update to 24.8 directly. > > /Simon