Why does pkg require you to remove other packages and how to keep them

V

Vladimir80

Why, when trying to install a new package via pkg, the installer wants to remove or reinstall all important software.
For example, there was a system version 10, the necessary software was installed on it, and it was always successfully updated to the latest versions of Freebsd 13.
For example I need to install openvpn
# pkg install openvpn
It demands to delete zabbix и mysq

Code: 
Installed packages to be REMOVED:
        cmake: 3.13.4
        libarchive: 3.3.3,1
        mysql80-client: 8.0.14
        mysql80-server: 8.0.14
        zabbix44-server: 4.4.7

New packages to be INSTALLED:
        easy-rsa: 3.1.5
        openvpn: 2.6.5
        pkcs11-helper: 1.29.0

Installed packages to be UPGRADED:
        liblz4: 1.8.3,1 -> 1.9.4,1

Installed packages to be REINSTALLED:
        lzo2-2.10_1

I understand that there is a library version conflict, but:
1. The question is the norm in the FreeBSD world and everyone lives like this.
What then should be done if it is necessary to save the old zabbix and the old mysql, and installing new programs would become possible?
There were thoughts of using pkg lock , but what about libraries like liblz4
what can help in this situation?

Or is it normal to remove the old and install a new one every three to four years?

2. Did I do something wrong at some stage, and if so, at what stage, is there some kind of “hygiene” to prevent this? Are there any best practices?
 
Zabbix 4.4 was removed almost 3 years ago (it's End-of-life). It probably has a dependency on one of the packages that is being upgraded. Because it depended on the 'old' version of that dependency it also needs to be upgraded if that dependency is upgraded. As there is NO Zabbix 4.4 any more, there's nothing to 'upgrade' and thus that old version gets removed.

Vladimir80 said:
Did I do something wrong at some stage, and if so, at what stage, is there some kind of “hygiene” to prevent this?
Click to expand...
You really need to be more diligent when it comes to installing updates. The "hygiene" you need to apply here is to update and keep up on a regular basis, at the very least once a month, preferably more often.
 
Vladimir80 said:
Did I do something wrong at some stage, and if so, at what stage, is there some kind of “hygiene” to prevent this? Are there any best practices?
Click to expand...
I'll agree with SirDice to update more often. Yes, it's hard when "it's not broken" or it's a production system, but the choice is a little bit of pain more often or a huge amount of pain every 3 or 4 years.

If you are using binary packages (not building from source), the quarterly repos (which you are tracking if you install RELEASE) do a major update every 3 months, but a lot of times security related updates happen more often.

I typically do "pkg upgrade -n" once a week to see there there are any updates, if so, what is getting updated. That gives me a chance to evaluate everything and take my time applying them.
 
When it comes to Zabbix you should probably track an LTS version of that. Less updates and the LTS version is supported for a longer period of time. Zabbix 4 LTS ended fairly recently, Zabbix 5 LTS is still supported (until 2025). But I recommend to upgrade to Zabbix 6 LTS as 5 will only get some security updates now.

www.zabbix.com

Get all the details of the full Zabbix release policy.

Zabbix is an enterprise-class, open-source monitoring solution that makes network and application monitoring simple.
www.zabbix.com www.zabbix.com

net-mgmt/zabbix5-server
net-mgmt/zabbix6-server

Upgrading Zabbix is usually fairly painless. But sometimes you will need to modify settings or convert some tables. Check the documentation beforehand.
 
Do I understand correctly that this situation is normal. It is necessary to constantly update (reinstall) the software in order to be able to install something new on the server. For example, there is MySql Server 5.7 on which MyISAM tables work faster than on MySql Server 8. Nobody wants to lose performance or change all the projects on a given server under Inodb, just because you need to install a utility that requires a newer shared library. What do you do in such cases?
Pardon the blasphemy, is the situation with conflicting versions of libraries and packages the same in the Linux world, or are they better at it?
 
MySQL 5.7 is EOL as well, so this isn't a good example either. There's no point in even trying to provide packages of EOL software, unfixed security vulnerabilities get more likely quickly, and as a distributor of a port/package, you'll have your share of responsibility.

In general, if the upstream projects of shared libs do sane versioning, it's perfectly possible to have two major/ABI versions of the same lib installed at the same time, and if both are supported, there's no reason not to offer it. Most Linux packaging frameworks support sub-packages which makes this a bit easier (a feature currently worked on for FreeBSD ports), but even without that, it's doable. You will most likely find a few examples where it is indeed done in our ports tree (edit: I currently happen to know one, we have ffmpeg at version 6.x and also ffmpeg4 for consumers of the libs that aren't compatible with the newest version yet....)

But, again, this will certainly never happen to support EOL software. EOL means EOL, please upgrade. "Edit2" here: If you think MySQL 5.7 was "better" for some reason and you don't agree with the end of support and/or the direction of newer versions, you should really address your complaints there and not at a project just porting/packaging what the upstreams provide.
 
Vladimir80 said:
Pardon the blasphemy, is the situation with conflicting versions of libraries and packages the same in the Linux world, or are they better at it?
Click to expand...
My opinion only, the same situation exists in Linux. A lot depends on the definition of what is supposed to happen in the package manager when dependencies are updated.
Everyone has different ideas on "what is correct".
 
mer said:
My opinion only, the same situation exists in Linux.
Click to expand...
I'm going to say the situation is even worse there. With a version upgrade you will be forced into a new version of MySQL for example. With FreeBSD you can keep control of this (setting DEFAULT_VERSIONS). While the default was changed to 8.0 for example, you could still set 5.7 as your default. Until the 5.7 port was removed entirely.
 
I'm facing a similar (sort of...) situation here.

I upgraded sabnzbd from 4.0.0 to 4.1.0, and sabnzbd is complaining that par2cmdline-turbo is not installed:

1698409616452.png


Now, the funny part: if I install par2cmdline-turbo, the system removes... sabnzbd!

1698409687662.png


which does not make sense at all...

How do you handle this situation?
 
Zamana said:
I'm facing a similar (sort of...) situation here.
Click to expand...
Not really, looks to be completely different issue.

sabnzbd has a runtime dependency on a par2repair binary that comes from par2cmdline package by default, and that dependency is recorded when packages are built, so when it's removed, sabnzbd is removed as well.
 
Zamana said:
Now, the funny part: if I install par2cmdline-turbo, the system removes... sabnzbd!
Click to expand...
Makes perfect sense to me: sabnzbd depends on par2cmdline, it doesn't depend on par2cmdline-turbo.

Zamana said:
How do you handle this situation?
Click to expand...
You complain to bapt@ (or portmgr@ in general), they agree with you and proceed doing nothing. I'm hoping for proper requires/provides support after they are done with subpackages, but I'm not holding my breath.
 
yuripv79 said:
sabnzbd has a runtime dependency on a par2repair binary that comes from par2cmdline package by default
Click to expand...
A small correction: the port depends on a binary. The resulting package depends on a package, there is no information about the dependency on that specific binary in the package manifest. Not everyone reading us is familiar with the distinction, especially since pkg actually tries to go beyond packages with shared library tracking. (You'd think that feature would be either canned or extended to other types of dependencies, but pkg development priorities never made any sense.)
 
You must log in or register to reply here.
Back
Top