You are not logged in.
Hello.
How do I install alternative packages, which are dependency of another package?
Lets see specific example.
I have displaylink package installed (it has evdi dependency) and evdi package installed.
Now I want to install evdi-pre-release. It conflicts with evdi (I edited pkgbuild). When I try to install it, I am asked to remove evdi, but if I agree to remove it, it says that I am braking dependency.
:: evdi-pre-release and evdi are in conflict. Remove evdi? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: displaylink: removing evdi breaks dependency 'evdi>=1.3.43'
I know that displaylink depends on evdi or evdi-pre-release. But package, which I am going to install resolves that dependency. How do I say it to pacman?
I could force remove evdi package and then install evdi-pre-release or just remove evdi with displaylink packages and then install evdi-pre-release and displaylink.
Which way is correct to do this task?
Last edited by Ashark (2017-06-01 13:06:33)
Offline
This is why versioned dependencies are a bad idea. Either ask the evdi-pre-release maintainer to version the provides field, or the displaylink maintainer to remove the version from the dependency.
Offline
EDIT Arojas gives a simpler way.
evdi-pre-release should provide, conflict and replace evdi .
a (rather bad[1] ) workaround is to remove evdi using -Rdd , then install evdi-prerelease .
[1]
using double d tells pacman to ignore dependency checking completely .
It can (and has done that in the past ) mess up a system beyond repair .
Unless you (or the person that advises you to use it) know what they are doing very well don't use it .
For this case it's the quick and dirty way to solve the issue.
The best way is to edit the evdi-pre-release PKGBUILD . that will allow pacman to solve this issue the correct way.
Last edited by Lone_Wolf (2017-06-01 12:16:39)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
It worked! Thank you for quick answer.
Marking as solved.
Offline
But the provided solution contradicts the wiki: https://wiki.archlinux.org/index.php/PK … _relations
For instance, a modified qt package version 3.3.8, named qt-foobar, should use provides=('qt=3.3.8'); using provides=('qt') would cause the dependencies that require a specific version of qt to fail
This evdi is not modified.
An array of obsolete packages that are replaced by the package [..].If providing an alternate version of an already existing package or uploading to the AUR, use the conflicts and provides arrays, which are only evaluated when actually installing the conflicting package.
The other evdi is not obsolete.
If it doesn’t do any harm, I will of course update the PKGBUILD.
Offline
replace was designed for obsolete packages, but can be used for other cases.
If A and B packages are functionally equivalent, having B replace A wil make it easy to switch from A to B letting pacman do everything needed.\
Many AUR git packages use replaces this way to make switching from stable package to git version easy.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yes, thanks for info.
Maintainer already has edited evdi-pre-release pkgbuild.
Offline
replace was designed for obsolete packages, but can be used for other cases.
If A and B packages are functionally equivalent, having B replace A wil make it easy to switch from A to B letting pacman do everything needed.\
Many AUR git packages use replaces this way to make switching from stable package to git version easy.
Using replaces for this is completely and totally wrong. Replaces are for when a package is renamed or something similar. If the package being "replaced" still exists, do NOT uses "replaces.
Offline