Change/ignore a package dependency

[vmisev]

With the mariadb client installed, I would assume it would simply use that without even noticing the mysql one isn't actually installed.

As I said pkg security/vaultwarden needs libmysqlclient.so.21 as dependency, not libmysqlclient.so that MariaDb provides, and with databases/mysql80-client libmysqlclient.so is simply link to libmysqlclient.so.21. Also, if you check databases/mysql80-client you'll see that is required by security/vaultwarden (expand "This port is required by:" and look under 115.) Only way around this is what DtxdF advised about DEFAULT_VERSIONS+=mysql=1011m

 

[SamKook]

Hmm, looks like you're right, mariadb doesn't create a symlink for that one.

I wanted to test it in a VM by manually making one but it turns out even manually installing all the dependencies and using install -M still refuses to not install mysql...

FreeBSD-Test# pkg install -M vaultwarden-1.34.1_1
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        mysql80-client: 8.0.42 [FreeBSD]
        vaultwarden: 1.34.1_1 [FreeBSD]

Number of packages to be installed: 2

The process will require 145 MiB more space.
14 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching vaultwarden-1.34.1_1.pkg: 100%    8 MiB   4.2MB/s    00:02
[2/2] Fetching mysql80-client-8.0.42.pkg: 100%    6 MiB   6.4MB/s    00:01
Checking integrity... done (2 conflicting)
  - mysql80-client-8.0.42 [FreeBSD] conflicts with mariadb118-client-11.8.2_1 [installed] on /usr/local/bin/my_print_defaults
  - mysql80-client-8.0.42 [FreeBSD] conflicts with mariadb118-server-11.8.2_1 [installed] on /usr/local/bin/perror
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        mysql80-client: 8.0.42 [FreeBSD]
        vaultwarden: 1.34.1_1 [FreeBSD]

Installed packages to be REMOVED:
        mariadb118-client: 11.8.2_1
        mariadb118-server: 11.8.2_1

Number of packages to be removed: 2
Number of packages to be installed: 2

The operation will free 205 MiB.

Proceed with this action? [y/N]: n

I'm still curious to know if it's possible to ignore some dependencies when using pkg though.

 

[vmisev]

I'm still curious to know if it's possible to ignore some dependencies when using pkg though.

Packages are not dynamic by their nature, they are sets of prebuilt binaries and libs, and everything in them needs what they were linked with at the time they were built. If you want to change what package expects, build it from ports, that's what ports are for.

Making jail for poudriere and your own repo is not a hurdle, and it will make it down the road much easier to update, upgrade and maintain custom built pkgs along with others from official repo.

 

[SamKook]

Yes, but there are still some ways to manipulate how packages are handled by locking some and that -M option(in theory at least, I've had no success making either of those 2 things work the 1 time I needed them) so it's not impossible, although it seems unlikely from what I found.

Since vaultwarden is compatible with mariadb(which is confirmed since the arch package uses it instead of mysql), there's a high chance just creating a symlink from libmysqlclient.so.21 to libmariadb.so.3(which is all libmysqlclient.so is or to libmariadb.so which symlinks to the .3 one and would make this work forever) would work perfectly fine and that would stay between updates.

I've managed to avoid the need to make custom pkgs for a very long time and I would prefer to keep things that way since I've killed a system in the past mixing ports and pkg and I'm not a big fan of jails/containers.
If I have no other choice, I will use them but I'm not there yet and I'm curious about this.

 

[vmisev]

What I can tell you, good luck.

 

[SamKook]

Talking about locking made me think of installing vaultwarden, locking it and then installing mariadb back and that only uninstalled mysql so everything is in place to test it.

It's just too late now to set it up so it'll have to wait for tomorrow.

 

[SirDice]

Talking about locking made me think of installing vaultwarden, locking it and then installing mariadb back and that only uninstalled mysql so everything is in place to test it.

Locking a package will also prevent it from being updated. So you'll need to unlock it and do this forced package dance every single time you update.

     The impact of locking a package is wider than simply preventing
     modifications to the package itself.  Any operation implying modification
     of the locked package will be blocked.  This includes:

     •   Attempts to reinstall, upgrade, downgrade, or delete the locked
         package itself.
     •   Installation, upgrade, or downgrade of a package where the resultant
         package would have a dependency on a different version of the locked
         package.
     •   Deletion, upgrade, or downgrade of any package the locked package
         depends upon, either directly or as a consequence of installing or
         upgrading some third package.

Set up your own repository or build from ports, use DEFAULT_VERSIONS to change the 'default' and build everything with the MariaDB version of your choice.

since I've killed a system in the past mixing ports and pkg

All the more reason to set up and use your own custom repository. Has a number of other benefits too. Like being able to revert certain updates, have more control over what gets updated at what time. You won't get surprised with defaults changing all of a sudden (because you set them yourself). Turn options on or off on specific ports, cut down the sometimes insane amount of dependencies for features you don't even need or use.

 

[cracauer@]

I know, that's exactly the problem I have, but what I was saying is that if the software supports mysql, that basically means it also supports mariadb.

Dtxdf even linked how to compile a port with mariadb using the mysql option:

If that is really the case and can be shown working in practice then then best way forward clearly is to work with the port maintainer to add mariadb as an option in the port.

I wouldn't be surprised if there are surprises, though.

 

[astyle]

When compiling a port, there's usually a make config option that allows you to change at least some of the defaults that a package is compiled with. I generally try to to turn off dependencies on stuff like MySQL/MariaDB and Java, using that make config option.

Editing the Makefile itself is also an option - if you know what you're doing with the port.

 

[SamKook]

If that is really the case and can be shown working in practice then then best way forward clearly is to work with the port maintainer to add mariadb as an option in the port.

I wouldn't be surprised if there are surprises, though.

Yeah, especially when their official wiki says this: Although MySQL database works fine, be aware that our builds are based upon MariaDB client libraries since that is what Debian provides.

But from what I understand, it's an issue with pkg lacking flexibility, it doesn't seem to have optional dependencies support so it has to install everything even if not needed and mysql and mariadb can't cohabit so it has to be one or the other.

 

[SamKook]

Locking a package will also prevent it from being updated. So you'll need to unlock it and do this forced package dance every single time you update.

Yeah, I know, but mariadb is a manual install and not a dependency so it's not really a big deal to lock and unlock it when needed and I'd need to do the compiling song and dance every time I want to update the other way so if locking works(I haven't tested if locking mariadb would actually install vaultwarden properly, I went in a roundabout way that had more chance of working right for the test), it sounds like less work to me, unless I'm missing something.

All the more reason to set up and use your own custom repository. Has a number of other benefits too. Like being able to revert certain updates, have more control over what gets updated at what time. You won't get surprised with defaults changing all of a sudden (because you set them yourself). Turn options on or off on specific ports, cut down the sometimes insane amount of dependencies for features you don't even need or use.

The problem is the mixing of ports and pkg so I'm not sure how this would prevent issues arising from that. If I was only using ports, then yeah, I'd have way more flexibility and freedom, but if I make a custom repo just for a few apps and mainly use pkg, I risk running into issues with shared libraries(which I did in the past). Even just with vaultwarden, half of its dependency are shared with other packages I have installed so there is a high risk of a mismatch at some point. Maybe there's something I'm not understanding?

The jail would isolate the issue to only vaulwarden so that's a decent alternative, but as I already mentioned, using those isn't my first choice.

 

[SamKook]

Finally managed to configure the vaultwarden test, really hate it when a software denies access to http other than the local machine, which is a pain when it has no GUI, which is why it took so long.

The pkg installation defaults to sqlite, there's not even the variable for the db connection in the sample file...
I did want to see if it would work though so I did set it up to use the local mariadb database and with the symlink from libmysqlclient.so.21 to libmariadb.so, it does work perfectly fine, as I suspected(I also made sure to check that it did write inside the db), and the vaultwarden UI does correctly identify the DB as mariadb with the correct version.
It does fail without that manual symlink though, it complains libmysqlclient.so.21 doesn't exist.

The problem is that locking mariadb doesn't prevent mysql from wanting to install itself so that doesn't work:

pkg: mysql80-client-8.0.42 conflicts with mariadb118-client-11.8.2_1 (installs files into the same place).  Problematic file: /usr/local/bin/my_print_defaults

So I'm back to the question of if there is a way to prevent a specific dependency from installing itself when using pkg.

 

[astyle]

So I'm back to the question of if there is a way to prevent a specific dependency from installing itself when using pkg.

Short answer: no.

The dependency hell is same on Linux and BSDs.

Sometimes, you just need manual overrides on a case-by-case basis.

 

[SamKook]

With the install -M switch, it might be possible, the question is what makes a package be considered missing for it to then be skipped and how would that be achieved.