Hi,
I would like to make a couple of suggestions about LibreOffice packages, just in case these may be considered ideas worth pursuing:
I think that it would be great to have — in parallel to libreoffice still and fresh versions — a libreoffice-fresh-rc package carrying the latest rc package in the fresh branch. This is because libreoffice RC packages are often quite stable and an excellent way to get the fastest possible turnaround in case of bugs.
I think that it would be great to get libreoffice updates asynchronous from the regular ~15-days manjaro cycle, similarly to what happens with, e.g., firefox that is typically delivered as soon as it is released from mozilla. The rationale is that a libreoffice update typically will not cause any rebuild of stuff depending on libreoffice and as such it could be provided early.
I think that it would be great to have a way to install libreoffice-fresh and libreoffice-still in parallel one to each other. Currently they conflict, but the libreoffice code is upstream not meant to have that conflict. The other way round, if you happen to be on some deb or rpm based distro, you can nicely download the LibO upstream binaries and install them in parallel. This has two great advantages: (i) on a multiuser system it lets some users be on LibO still while others may prefer fresh; and (ii) it offers an exellent way to check if some issue is due to a regression in the fresh codebase. The only problem with the parallel installation is that you must decide whether libreoffice links to the fresh or the still version (e.g. to libreoffice7.3 or libreoffice7.2 as of today). That could be solved either with an alternatives system (a la debian) or with an helper package libreoffice-is-fresh or libreoffice-is-still just in charge of providing the system level link.
The reason why I am proposing these changes is that I feel it strange that a rolling distro typically ends up lagging wrt to the LibO version wrt debian/ubuntu/fedora where LibO can be kept fully up to date thanks to the upstream binary packages (or maybe even a dedicated ppa for ubuntu). It also feels a bit strange that an arch inspired distro ends up offering less control and flexibility by forbidding parallel installs.
Manjaro is, has always been, and has always said it is, a curated rolling release. Which mean that the Manjaro Team tests and work out all kinks in the software before it comes to you, making it much easier for you to use and work with. I don’t know 'bout others, but I like it this way.
Anything different and I highly doubt it’ll be Manjaro anymore.
Check out the Flatpak release for it, it might be what you’re looking for:
I totally understand this, and it was certainly not my intention to appear as complaining about anything! My though was about LibO looking a bit like firefox an application for which issues could at most break just the application itself. And because firefox appears to have a quick asynchronous update process, I was wondering whether that could be OK for LibO too. But probably the async updates for firefox are dictated by the fact that there are way more security implications there.
Thanks for the suggestion about flatpak (unfortunately, I do not think that you get still and RCs there).
Maybe the best option would be work with AUR. I think that there was a package there to get the binaries from the upstream RPMs and repackage them, maybe I could check that and make variants for the RCs.
More important: do you have any opinion, idea about the parallel install option? That IMHO would be quite valuable.
I do. I think it’s unnecessary and perfectly fine as it is. I personally have no use for the older version. Especially with the newer version as well. I think you could install the older version with Flatpak and the newer one directly? That’s also an option. But, personally, I think it’s completely unnecessary. I don’t think it’s a widely-required feature. In fact, I might be wrong, but I think you’re the only one that’s requested it.
Arch Linux and by inheritance Manjaro - do not support multiple version of the same package. The only way to have that is to manage the things yourself outside the default package-manager (by compiling the older or newer RC version yourself in /usr/local/bin) or to make another non-conflicting package by yourself, with custom install location. I do not think there is any other mechanism to have multiple versions installed.
paraphrasing a reply from some time ago from elsewhere
As a matter of fact I think that this considerations applies to making available two version of the same package (read same name). Here, we have 2 versions of libo that are already independently packaged in two different packages with different names precisely to support the choice between the them (correct me if I am wrong as I am a novice to manjaro). Seems very much the same thing that goes on with python where two versions (python 3 and python 2 are supported by packaging them in packages with different names).
What I am now understanding (and again I may be misinterpreting, so correct me if I am wrong) is that python is very much of an exception in allowing the parallel install of the two different versions and that for anything else by policy such a provision is discouraged even if the upstream developer catered for it. This is understandable, because it would require a somehow increased packaging effort.
As a final comment, I got the impression that my questions may have got interpreted as if I were the totally new one coming around to criticize. Please, do not get me wrong, that was not the intention at all! I only had a few thoughts that seemed valuable to me and wanted to share them and understand if other could be considering them worth.