request for advice about conflicts

cryptearth · Today 06:07:40

So I just did a yay update and got noted https://aur.archlinux.org/packages/icaclient is marked out of date. So I looked up the aur index https://aur.archlinux.org/packages?K=icaclient and noted "Oh, there's a -beta package?": https://aur.archlinux.org/packages/icaclient-beta
The -beta package has the base package as conflict, the base package has the -beta not as conflict.

I tried to build icaclient-beta - but this ended up in yay giving up after about 3 retries to compile dependencies (if I spotted correctly it seems the webkit package, again, which I remember there was a rather lengthy topic about - but that could be my system, haven't tried it in a clean VM).

Anyway - my question, as I'm unable to test it myself: Is it sufficient if only the -beta package contains the conflict? Or does the base package need it, too?

Thanks everyone.

killertofus · Today 07:36:19

suppose you have a package called foo, what foo does is a simple calculator app, the upstream maintainer snarf, has made a appimage/repo specific package (eg deb/rpm) and tar files, for the linux users now you as a user of foo wants to put it into the aur you have three choices, vcs packaging[1] -bin package for statically loading libraries eg you don't need to use yarn to build it if it's already prebuilt.

Now you as the downstream/aur maintainer get to decide what gets provides/conflicts/replaces saving replaces for very specific reasons eg eza replacing exa as for replaces/conflicts[2] you should not for standard packages eg non git/bin packages put the package name for conflicts/provides instead if the package does provide a common library eg ctags provides universial ctags[3]

Now for non standard packages eg -bin/git you do need to provide/conflict the package name so you can't install both foo and foo-bin you will have to pick one to install and one to remove, the question the user will want to decide is, do they want the newest version eg git, prebuilt for less compile times, now for beta/nightly packages they follow the same as the git-bin version as they need to provide/conflict the non beta/nightly eg foo-beta will provided foo and conflict foo but if you package foo-beta-bin you will need to provide foo and foo-beta with conflicts with foo-beta and foo

now if you want to make compiling faster for this package, the maintainer of webkit2gtk has a prebuilt version on there own website/repo

[1] https://manual.archlinux.page/package-guidelines/vcs/
[2] https://manual.archlinux.page/package-g … -relations
[3] https://archlinux.org/packages/extra/x86_64/ctags/

seth · Today 08:27:51

The -beta package has the base package as conflict, the base package has the -beta not as conflict.

Welcome to the AUR

It's hard to imagine how a unilateral conflict could even be a thing and typically packages will mutually conflict each other, but for that to happen the maintainer needs to be aware of the competitor.
=> drop a comment at icaclient letting the maintainer know about the situation.
This will however probably not be the cause of your compilation problems (provided you've removed the other package first)

Lone_Wolf · Today 10:51:59

It's hard to imagine how a unilateral conflict could even be a thing and typically packages will mutually conflict each other,

Disagree.

Not sure if it is mentioned in arch packaging guidelines, but common practice for archlinux packages is :

One version is the primary version, all other versions either cooperate with the primary or conflict with it.
Typically the latest stable release of the package build from source is used as the primary one.

Look up llvm versions in repos if you want an example.

Icaclient is the primary version , all variants of it need to cooperate with icaclient or conflict with it .

Note : I'm leaving provides= out of this to keep things simple.

seth · Today 11:05:20

But llvmNN do not conflict w/ llvm in either direction?
My point was that if A conflicts w/ B, B conflicts w/ A by inference and that of course should™ be reflected in the metadata of both packages, but w/ the less organized AUR you can easly have B showing up and mark itself in conflict w/ A but the maintainer of A isn't aware that B even exists.

Lone_Wolf · Today 12:14:20

myself wrote:

all other versions either cooperate with the primary or conflict with it

My example may not have been the best choice , as the llvmNN packages all use the first option : cooperate with the primary.

Suppose A , A1 , A2 , A3 , A4 all exist and each lists the 4 alternatives as conflicts .
Now A5 appears on stage.

Should A , A1 , A2 , A3 , A4 maintainers all add a conflict with A5 ?
And does that need to be repeated when A6 & A7 surface ?

What if A3 disappears ?

Or should A be treated as primary and every alternative either conflicts with A or makes sure it can coexist with A ?

seth · Today 15:32:35

Should A , A1 , A2 , A3 , A4 maintainers all add a conflict with A5 ?

Ideally yes, "should" … and in the repos you'd kinda expect that.
See eg. https://archlinux.org/packages/extra/x8 … ire-pulse/ and https://archlinux.org/packages/extra/x86_64/pulseaudio/

The practical issues in an environment like the AUR or (3rd party repos) was the caveat acknowledged in my first response and the mutual flag is also not strictly required (pacman will raise the conflict no matter what because the mutual conflict is implied), but it seems good style that if you're aware of a conflicting package, you formally record that in the PKGBUILD

Or should A be treated as primary and every alternative either conflicts with A or makes sure it can coexist with A ?

Who decides (on the AUR) what the "primary" is - and how?
And if the concerned parties are seeking cooperative agreement on that, they might just as well record the conflict, no?

Arch Linux

#1 Today 06:07:40

request for advice about conflicts

#2 Today 07:36:19

Re: request for advice about conflicts

#3 Today 08:27:51

Re: request for advice about conflicts

#4 Today 10:51:59

Re: request for advice about conflicts

#5 Today 11:05:20

Re: request for advice about conflicts

#6 Today 12:14:20

Re: request for advice about conflicts

#7 Today 15:32:35

Re: request for advice about conflicts

Board footer