request for advice about conflicts

cryptearth · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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?

Lone_Wolf · Today 10:16:41

pipewire and pulseaudio are different softwares with different goals that have some overlap in functionality and should both be treated as primaries, not as variants.

seth wrote:

Who decides (on the AUR) what the "primary" is - and how?

https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission wrote:

If the package is an alternate version of an already existing package, use conflicts

First come, first served ?

The suffixes for VCS package naming parts and proprietary code combined with arch habit of preferring source builds of latest stable releases suggest that any package with such a suffix should never be treated as a primary.

cryptearth · Today 12:46:43

First off: Thanks for the many replies.
Let me redifine my question: As I'm not able to test because of building failure, what WOULD happen when one of the two packages is installed (no matter which) and one tries to install the other one? From what I understand: As long as at least one package has the other in conflict it should always raise an error, correct?

For Citrix specifically it's important that the client is as close to the server version as possible, in best case equal. As I neither control the citrix server of my employer nor am I able to get specific information (although I do have some contact to the IT guys. but due to some stupid ISO certification and recent changes to it we're no longer allowed to use private hardware but have to use hardware given by the IT; let alone using Linux was "banned" (as in: not supported) long time ago) I rely on a rather recent package - no matter who provides it or how it's done. So, given I may have to switch to the more recent -beta package for compatibility but then later the "regular" one catches up again so I can switch back to it: Both switches should raise the conflict error, becuase the -beta package has the non-beta package in conflict, right?

seth · Today 15:13:26

@Lone_Wolf

First come, first served ?

What if the "primary" version becomes stale?

pipewire and pulseaudio are different softwares with different goals

Both are userspace sound daemons… what about https://archlinux.org/packages/extra/x8 … ice-fresh/ and https://archlinux.org/packages/extra/x8 … ice-still/ ?

What it I have A1 installed and want to install A2? Both list conflicts w/ A but not against each other and I don't have A.

@cryptearth

As long as at least one package has the other in conflict it should always raise an error, correct?

Yes, otherwise you'd run into https://wiki.archlinux.org/title/Pacman … )%22_error

Arch Linux

#1 Yesterday 06:07:40

request for advice about conflicts

#2 Yesterday 07:36:19

Re: request for advice about conflicts

#3 Yesterday 08:27:51

Re: request for advice about conflicts

#4 Yesterday 10:51:59

Re: request for advice about conflicts

#5 Yesterday 11:05:20

Re: request for advice about conflicts

#6 Yesterday 12:14:20

Re: request for advice about conflicts

#7 Yesterday 15:32:35

Re: request for advice about conflicts

#8 Today 10:16:41

Re: request for advice about conflicts

#9 Today 12:46:43

Re: request for advice about conflicts

#10 Today 15:13:26

Re: request for advice about conflicts

Board footer