Wishlist about Libreoffice packages

Hi,
I would like to make a couple of suggestions about LibreOffice packages, just in case these may be considered ideas worth pursuing:

  1. 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.

  2. 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.

  3. 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.

What do you think?

With all due respect,

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:

https://www.libreoffice.org/download/flatpak/

4 Likes

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.

Thanks for the clarifications.

1 Like

What you wish for is impossible given the nature of how system maintenance works.

Also see the Talk page on system maintenance

You may want to educate yourself on the ABS (Arch Build System) and the native package manager pacman

Technically you are asking for problems - such system is in a partially synced state is unsupported.

Manjaro follows Arch and thus the filesystem hierachy laid out by systemd.

If you look carefully in your root you will see symlinking of inportant folders into the same destination

$ ls -l /
total 80
drwxr-xr-x   6 root root  4096 12 mar 13:28 a
lrwxrwxrwx   1 root root     7 18 dec 16:21 bin -> usr/bin
drwxr-xr-x   5 root root  4096 13 mar 15:05 boot
-rw-r--r--   1 root root 13272  4 mar 13:07 desktopfs-pkgs.txt
drwxr-xr-x  21 root root  4400 16 mar 18:30 dev
drwxr-xr-x  84 root root  4096 15 mar 05:43 etc
drwxr-xr-x   3 root root  4096 12 mar 13:23 home
lrwxrwxrwx   1 root root     7 18 dec 16:21 lib -> usr/lib
lrwxrwxrwx   1 root root     7 18 dec 16:21 lib64 -> usr/lib
drwx------   2 root root 16384 12 mar 13:23 lost+found
drwxr-xr-x   2 root root  4096 18 dec 16:21 mnt
drwxr-xr-x   6 root root  4096 13 mar 15:08 opt
dr-xr-xr-x 370 root root     0 16 mar 18:30 proc
drwxr-x---   8 root root  4096 12 mar 13:24 root
-rw-r--r--   1 root root  5171  4 mar 13:07 rootfs-pkgs.txt
drwxr-xr-x  25 root root   580 16 mar 18:30 run
lrwxrwxrwx   1 root root     7 18 dec 16:21 sbin -> usr/bin
drwxr-xr-x   4 root root  4096  4 mar 13:06 srv
dr-xr-xr-x  13 root root     0 16 mar 18:30 sys
drwxrwxrwt  13 root root   440 16 mar 18:32 tmp
drwxr-xr-x   9 root root  4096 15 mar 05:41 usr
drwxr-xr-x  12 root root  4096 15 mar 05:43 var

This strucure makes it impossible for several versions of the same so-name for different usecases.

If you prefer such possibililties - I’d recommend Debian.

In fact - this simplified system is one of the reasons I use an Arch based system.

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.