LibreOffice (classic package) release installed to freeze up for coming 24 months

[Dyrr]

Used Manjaro release: 23.0.0

For Manjaro installation here there is the desire for LibreOffice package not to upgrade to higher release versions withing coming 24 months - package release freeze-up. Currently it is 7.4 and it needs to keep be at this version.

I guess it won’t suffice to make a lock on Manjaro computer side only. I think it can work only if in mentioned time perspective Manjaro repositories provide that version among all coming Manjaro updates and upgrades. Alternatively Manjaro computer administrator will need to conduct package backport every time such is necessary - which in this particular case is problematic due to lack of free resources.

Can freeze-up pointed out work?
Which steps are to be completed in order to implement it?
How to perform version lock on repository client side?

[Mirdarthos]

Hi @Dyrr,

You are welcome to add the package to IgnorePkg in /etc/pacman.conf, in which case it won’t be upgraded.

Edit the file as root:

sudo nano /etc//etc/pacman.conf

Locate the line starting with

#IgnorePkg

…remove the comment (#) in front of it, and add the package to the end of it. Similar to:

IgnorePkg = libreoffice-still

However, fair warning: this will result in a partially upgraded system, and is not supported when not if - but when, the system breaks.

[megavolt]

Hello @Dyrr

I understand you intention, but a freeze on specific version is not supported on a rolling release model, since applications often depend on other libraries, which can have breaking changes on upgrade, thus the application can not run anymore.

You can do what @Mirdarthos suggests, also the pamac-manager supports it in the GUI:

But it should always be a temporary solution to lock a specific version.

Maybe a flatpak would be better fit your needs… example:

1. Check the application id:

flatpak list --columns=name,application

2. Check the remote commits

flatpak remote-info --log flathub org.libreoffice.LibreOffice

3. If you need a to stay at a specific version, then look at the Subject and copy the Commit Hash.

4. Now update (downgrade) it to the specific commit:

sudo flatpak update --commit=dc9bfcabb9228a3b2be753107c284149be02a4575acdf9b8c77fb1bbd6229000 org.libreoffice.LibreOffice

5. If you want to prevent it from downgrading, then mask it:

flatpak mask org.libreoffice.LibreOffice

6. If you want to update it then unmask it and run an update:

flatpak mask --remove org.libreoffice.LibreOffice
flatpak update

Why flatpak? Because it delivers its own libraries and don’t rely on system libraries. That way, you would have the exact version directly delivered from the LibreOffice developers in that case.

[Dyrr]

Thanks for hint.

Several other apps are in use for long time as (Canonical) snaps, eg. web browser of few different brands. These have problem to access removable media mounted under /mnt or /media. Hence I hesitate to use more sandboxed apps as far as critical mission is background, the fear to run onto numerous problems while using sandboxed app as there are very little till no free resources for troubleshooting.

EDIT
Furthermore, LO Writer needs to have working connection to one 3rd party app. Troubles can arise here as well - will need clarification if incorporation that 3rd-party app to flatpak-app is already implemented and well-working. In worst case to be incorporated by own power and resources (problematic), accepting the risk of further problems in future.

[Dyrr]

@Mirdarthos

You are welcome to add the package to IgnorePkg in /etc/pacman.conf, in which case it won’t be upgraded.

How are chances frozen LO at state of 7.4 to be functional coming 24 months along with Manjaro which undergoes continues update/upgrade process?

[Mirdarthos]

It might be a month.

It might be 6.

It might be 12.

It might be 24.

It might even be 36.

I can’t say. Perhaps someone else can, but I doubt it.

[philm]

Manjaro is a rolling release. Even the libreoffice-still might get updated to the next version when the old version is moved to the still branch. You can see that in the history of package updates: Commits · main · Arch Linux / Packaging / Packages / libreoffice-still · GitLab A dot-7 normally marks the last version of a series of LibreOffice. So the next update to still branch most likely will be 7.5.5. Then there are rebuilds due to libs updates like python, icu or poppler.

Best bet here is to decouple LibreOffice from the OS and use some like flatpaks.

---

Another option would be to contact our commercial support and ask for a quotation to see what can be done on your special case.

[Dyrr]

@philm

Even the libreoffice-still might get updated to the next version when the old version is moved to the still branch.

Manjaro still branch is in use here.

[megavolt]

@Dyrr

Several other apps are in use for long time as (Canonical) snaps, eg. web browser of few different brands. These have problem to access removable media mounted under /mnt or /media.

No idea about snaps, but flatpak has nice GUI to manage this: Flatseal
Under “Filesystem” you can simply add the path /media and /mnt. The app will have access to directory recursively.

@Dyrr

Furthermore, LO Writer needs to have working connection to one 3rd party app.

Understand, but also doable. Anyway… did you know that there are appimages? Maybe that could fit your needs, since these AppImages are not sandboxed and will never update itself:

• LibreOffice as AppImage | LibreOffice - Free Office Suite - Based on OpenOffice - Compatible with Microsoft
• https://appimages.libreitalia.org/

Just mark it as executable, run it.

[philm]

LibreOffice normally ends with a dot-7 release. A new LibreOffice-Still starts with a dot-5 release. Collabora Office 22.05 is based on 7.3.7 release and has 2 years LTS support you have to pay to Collabora. This may include security fixes and updates. However Arch/Manjaro might not be supported as they aim for a non rolling release like Ubuntu LTS and others.

Sure you can freeze the final dot-7 release of any LibreOffice version by using appimages, snaps or flatpaks. However the software will be not updated, not maintained and might gain security issues over the years.

Hence the still branch of LibreOffice gets constantly updated in a slow paced rolling release model.

[linux-aarhus]

Why 24 months?

Is the task to maintain a coherent business network?

@Dyrr

Which steps are to be completed in order to implement it?

Create your own repo service either public interface or hosted internally on company network.

@Dyrr

How to perform version lock on repository client side?

This can be done using two methods - both will house on or more s.

In either case you will need to create and implement a strategy to handle the security issues which may arise from your chosen system(s) configuration.

Another possible pitfall to consider is the possible overlap between system packages and possible dependency packages required for those apps you want to freeze.

No matter how you choose to implement - you will need a reference system image which you can use to create a system which can be used as reference for future updates and thus you can know beforehand which issues will arise when you roll out the update on the local mirror.

The simple method

1. Copy the relevant package files to own curated repo containing the packages you want to freeze
2. Insert your custom repo above distribution repo in pacman.conf

The advanced method

This method can keep all computers in the network sync with your own curated repo.

1. Sync the entire Manjaro stable repo from an rsync capable mirror
2. Implement an exclude list for the rsync command excluding the packages you want to freeze
3. Install a pacman-mirrors enterprise package on all systems to ensure coherent mirror pool
4. Sync your mirror with regular intervals to keep up with security patches