How to (sanely) handle conflicts between core packages and AUR?

Hello!

I'm having the following issue with Guix from AUR: Guix requires gnutls to be built with Guile bindings. The maintainers of the official gnutls package from Arch have apparently opted to explicitly disable Guile bindings when building the package, which is propagated to Manjaro's repositories. Therefore, the guix package now requires gnutls-guile, which in turn conflicts with with the official package as both provide gnutls binaries. This would not be a huge problem by itself, as both packages (atleast at the moment) provide the same version of gnutls, and any packages requiring gnutls should work fine with gnutls-guile. However, because pamac-common is a core package and requires gnutls, installing gnutls-guile results in failure if pamac-common is installed. I've been able to work around this by removing the gnutls dependency from .PKGINFO and then reinstalling pamac-common from the modified archive, but this seems less than ideal, as I suspect I'll have to do this every time pamac-common recieves an update.

So my question goes: Is there a recommended way of handling this type of situation without altering core packages? If not, what would be an appropriate way to automate this? Perhaps pre-transaction pacman hooks? If so, I'd appreciate some insight into manipulating packages this way, as the alpm-hooks official documentation seems not to mention anything about it.

Thanks for any and all replies.

P.S. On a completely unrelated note, I've been using the Manjaro i3 community edition for the past year, after a couple of years on Ubuntu (and being exposed to alot of Debian at work). I'm currently running it on 3 separate machines (2 laptops and a home workstation) and I have to say, so far it's been an absolute delight, even when I manage to break it. Big thanks to everyone involved with maintaining Manjaro!

You report the conflict to the AUR package maintainer - you can't remove [core] packages as they are assumed to be installed.

If you want to force the change you can do so as gnutls-guile says it provides=(gnutls). Have a look at pacman's dd flags.

By using a different package manager you're already in "Yes, yes, yes, I know what I'm doing" territory.

Make sure you have backups and a live installer prepared and to hand.

1 Like

Thanks for replying!

Are you referring to the --nodeps flag? Wouldn't that ignore all dependency version checks, where I would just like pacman to respect provides=(gnutls).

I'm only using Guix as a way of managing Guile packages, as those are scarce even in the AUR. I have no intention of replacing pacman with it.

Yes.

If you're removing gnutls which other packages depend on then you will get an error when you try to remove it.

But before you do that, what is the exact output when you try to install the gnutls-guile package (and when you use pacman -U directly on the package)?

When trying to install guix (or just gnutls-guile) without previously editing the pamac-common package I got:

could not satisfy dependencies:
removing gnutls breaks dependency 'gnutls>=3.4' required by pamac-common

in pamac-manager and a similar error in yay.

When I installed the edited pamac-common package with pamac -U, and then went on to install guix through yay, the install went through without errors even though there are other (non-core) packages that depend upon gnutls. Also, all of these packages now have gnutls-guile correctly listed as a dependency (I'm assuming due to provides=(gnutls)). Additionally, I have tried reinstalling some of these packages (vlc and wget) to see if it would raise any errors, and it didn't, but when I try to reinstall pamac-common after having installed guix I get:

could not satisfy dependencies:
removing gnutls-guile breaks dependency 'gnutls-guile' required by guix

(in pamac)
So I'm assuming that's what I'm going to get when updating pamac-common as well.

EDIT: Installing gnutls-guile directly from the package just gives:

invalid or corrupted package (PGP signature)

which I'm unsure how to handle.

Editing

That is indeed a knot. However, the guixpackage is an AUR only package and there is no warranty for conflicts with system packages.

That essentially means that some packages which works on Arch may/will not work on Manjaro.

Maybe a conflict can be added to the pamac-common package so guix will be marked as a conflicting package.

The unknown key has been mentioned several times on this very forum.

Pamac GUI will prompt you to import the key if not found.

I know it has been done with other Arch and AUR packages.


On a sidenote one has to wonder what good the guix package brings in as it is a package manager but not for Manajro / Arch.

It claims to be distro independent - but I think that does not apply to Manjaro as Arch based system.

Arch uses pacman and are very strict about file ownership and installing software and files using other means than pacman will sooner rather than later lead to file conflicts which are hard to solve.

Not sure how that would be productive, as gnutls-guile functions identically to gnutls other than having added Guile bindings. I have been using guix, along with the rest of my system fine since installing guix the way i wrote in my original post. Sure, no warranty can be given for AUR packages but most of us are aware there is some inherent risk when using them.

As stated in a previous post, I'm just using guix as a tool for managing maintained packages of Guile modules (think pip), as it's slowly becoming a pain to manually build most of the ones i want from git repositories. The AUR has only a handful of packages for Guile modules, official Arch (Manjaro) repositories have virtually none, while Guix has loads.

EDIT: Perhaps the question was misread here, I wasn't asking for help with installing guix, I have already done that. I'd just like to know if there's a standardized way of permanently making pamac-common locally respect gnutls-guile as a substitute for gnutls, or atleast to just make it ignore that one single dependency (not all dependencies like with --nodeps).

You need to add a version in the provides string of your gnutls-guile PKGBUILD:

provides=(gnutls=x.y.z)

3 Likes

I think you would be better off using guix on an archhurd.org system because Arch based system is very strict about files.

And I understand your issue - as you would like pamac to accept either implementations of gnutls.

I am pointing out that some packages available for Arch is not usable on Manjaro - like dpkg or apt-get.

But @guinux is the man as he is the developer of Pamac.

This diff will address the issue:

diff --git a/PKGBUILD b/PKGBUILD
index b09f668..fc8b1b2 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,7 +13,7 @@ options=('!zipman')
 depends=('gcc-libs' 'libtasn1' 'readline' 'zlib' 'nettle' 'p11-kit' 'libidn2'
          'libidn2.so' 'libunistring' guile)
 checkdepends=('net-tools')
-provides=($_pkgname)
+provides=($_pkgname=$pkgver)
 conflicts=($_pkgname)
 source=(https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/${_pkgname}-${pkgver}.tar.xz{,.sig})
 sha256sums=('aa81944e5635de981171772857e72be231a7e0f559ae0292d2737de475383e83'

I've reported this on the AUR package page.

@guinux @jonathon Just what I was looking for, just did exactly this on my other system and got no errors. Marking guinux' reply as solution since he was the first to mention it. Thanks guys!
I'll go bring that up to the maintainer of gnutls-guile. Nevermind, didn't see you already have.

@linux-aarhus

I don't see why that would be a must. Guix can build packages in an environment separated from the core system (as I understand, this is the default when used on what they call a foreign distro, instead of on GuixSD). That kinda seems like saying that conda or npm will eventually break a system.

Using sudo pip install instead of pip --user install will do for example

Ofcourse, but you don't have to use pip with root privileges. Neither do you have to use guix under sudo.

But that is how Arch work and by inheritance Manjaro.