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

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

+1: From Arch package guidelines (heading 5):

"List all direct library dependencies."

@Morganamilo, please read my polite proposal, and kindly consider declaring openssl or preferably libcrypto.so and libssl.so, which are direct link-level SO-versioned dependencies of paru, in your PKGBUILD.

Otherwise paru can automatically and silently break itself if it removes the legacy version of openssl (like 1.1), even as part of a recursive removal of some other package.

@MarsSeed TL;DR: You didn't follow the basic steps of packages on the AUR and were shocked when randomly removing packages somehow broke your setup.

Your proposal is the most disruptive for end users, and is also not the way packages are handled on the AUR generally.

I get the feeling that you may not have noticed who it is who packages this program? I'm pretty sure a TU knows the rules, the common practices, and the best way to handle this sort of "issue"

Please stop tagging me in your inane ramblings, if you want to get aggro at the packager for packaging it in a way that doesn't suit you, then IRC exists. This comments section is not the place to go off on some crusade.

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.