Arch Linux User Repository

you're better off contacting her via the github, this comments section is 90% "it's out of date" from people who didn't scroll down before posting

TLDR: Paru can break itself if the paru package does not properly declare its direct dependencies like openssl (libssl.so).

Actually I did not directly remove openssl-1.1 today, I removed some benchmarking tools from AUR (basemark and unigine-superposition), and I used recursive removal.

That was when paru chose to remove my openssl-1.1 package automatically, thus breaking itself, because my instance of paru was built in Aug 2022.

A package manager tool like paru should absolutely try not to break itself, or at least warn the user and give them a choice about it. :)

@haxie I believe you do not properly understand how packaging works in Arch.

.SO dependency in a pacman package is dynamic: pacman looks up which packages provide the declared SO version.

Last August, the openssl package provided libssl.so.1.1.

Today, the openssl-1.1 package provides libssl.so.1.1.

SO versions mean API versions. You seem to confuse this topic.

If my local paru package has a depends=('libssl.so=3-64'), Arch can still update openssl to 3.0.x versions, maybe even 3.1.x versions, as long as any Arch package provides libssl.so=3-64', pacman/paru will be able to upgrade the system.

Don't try to make me seem stupid when it is you who do not understand what you are saying.

Paru has a direct depencency on openssl, not an indirect (transitive) dependency.

Therefore it should be declared in PKGBUILD.

My proposal (depends=('libssl.so')) is the most flexible and least disruptive way to do a versioned dependency declaration.

And it is the most helpful and graceful for users.

@MarkSeed Unlikely doesn't mean impossible. The openssl package always points to the latest version... and a new openssl-3 or whatever package would only be made if things actually need it. paru doesn't actually require a specific version of OpenSSL It's also possible for an openssl .so bump, but not bump the api, leading to no package being added

And yes, theoretically in that case, uninstalling paru, going through that and reinstalling paru is indeed a solution... But is a godawful experience for users, and will drive them away from paru. Unlike the current way things are handled, which is the same way most packages handle it, which is, as there's a new OpenSSL version, rebuild your packages. Far far easier.

What happened today was you removing a package without actually checking things. AUR helpers are not a substitute for due diligence. Please make sure to check packages before doing so in the future.

And anyway if the locally built paru would prevent sysupgrade, then one would just need to uninstall paru, upgrade the system with pacman, then rebuild and reinstall paru.

This would still be a preferable scenario, because the users would be correctly informed about the dependency.

What happened with me today is the worst case, a total failure of dependency management due to lack of proper feedback to user before they remove a hidden but needed dependency.

@haxie, the hypothetical outcome you mention is totally unlikely.

If the new OpenSSL will have a main SO version bumb, Arch devs will create a new versioned package like openssl-3, similarly as they created openssl-1.1 when they updated openssl from 1.1 to 3.0.

If today's build of paru needs openssl v3.0, then let's say tomorrow Arch updates to openssl to 4.0 (fictitious number as of now), then they will also upload an openssl-3 package which contains the needed libssl.so.3 file.

If my recommendation in my last comment is followed, today's build of paru will depend correctly on the fitting openssl package as long as Arch carries the legacy version (which is typically at least a year in my experience).

@MarsSeed That will make it so you cannot upgrade OpenSSL, as Paru will depend on that specified version. And paru requires the newer version of OpenSSL to be installed before it, as it needs to build against it.

Based on this experience, my best recommendation is to add the following dependency to PKGBUILD:

depends=('libssl.so')

It will cause makepkg to create the package which depends on the main SO version available at build-time; currently:

Depends on: libssl.so=3-64

Or it would have been depends='libssl.so=1.1-64' last August, and pacman would have been automatically able to decide that today my locally built paru needs the openssl-1.1 package and not the main 'openssl' one which is at v3.0.

@MarsSeed OpenSSL is a dependency of multiple of paru's dependencies, including pacman itself.

It's a common theme across many packages on the AUR, specifically those built from source, that they will need to be rebuilt after an OpenSSL version bump. You are not the first to encounter this, and will not be the last. Take a look at the arch subreddit or in the IRC channels any time this has happened in the past, it's a support nightmare.

That package hook didn't work simply because paru doesn't specify a required OpenSSL, it just builds against your current system's version... as a result, there is no way for the PKGBUILD to signify what version it requires, and so cannot warn you against removing an old OpenSSL version.

I'll hazard a guess that not just paru broke with you randomly removing openssl 1.1 I suggest not removing packages from your system unless you're sure that it will not break something.

Breaking issue: openssl is an undeclared dependency.

To make matters worse, the build process links to the latest openssl installed, version-dependently.

The last time I built paru was in Aug 2022, and my binary got linked to v1.1 of openssl package.

Today Arch's openssl's main version is 3.0.

I uninstalled openssl-1.1 today using paru, and after that, paru refused to work:

$ paru -Rns openssl-1.1
checking dependencies...

Package (1)  Old Version  Net Change  
openssl-1.1  1.1.1.t-1       -5.52 MiB

Total Removed Size:    5.52 MiB

:: Do you want to remove these packages? [Y/n] y
:: Processing package changes...
(1/1) removing openssl-1.1     [----------] 100%
[...]

$ paru -Syu
paru: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

I had to rebuild paru in order for it to be linked to openssl 3.0.

And due to my system having had both openssl 3.0 and openssl 1.1 installed, my check-broken-packages-pacman-hook-git did not notify me that paru was linked to the old openssl-1.1 and in need of a rebuild.

@motolav maybe just increase the number so that it is no longer confusing.