You are not logged in.
I came across a package in the AUR with the same entries in its PKGBUILDS's 'provides' and 'conflicts' array. Isn't it implicit that installing a package which provides 'foo' should uninstall any previous 'foo' package?
Last edited by Gradient (2013-09-17 20:48:20)
Offline
It's done with packages from the repos too, so I guess it's not implicit https://projects.archlinux.org/svntogit … s/mplayer2
Offline
There is no reason that conflicts and provides should imply each other.
If pkg 1 contains binaries (or libs, or whatever) A B and C, and pkg 2 contains A B and D, then they conflict, but neither one provides the other. If pkg 2 contained A B C and D, then they'd conflict, and 2 could provide 1 (but 1 couldn't provide 2). Packages can also provide things that aren't even packages, like common-lisp: there is no common-lisp package in the repos, but there are a couple packages that provide common-lisp.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Still, I don't understand. If pkg1 provides A, then necessarily it conflicts with pkg2 that also provides A? Which means that 'provides' implies 'conflicts'.
Let's take this simple PKGBUILDS as an example. Why the need for duplicates entries?
Last edited by Gradient (2013-09-17 19:29:12)
Offline
Both cronie and fcron provide cron and thus they conflict with each other.
https://projects.archlinux.org/svntogit … ges/cronie
https://projects.archlinux.org/svntogit … ages/fcron
$ pacman -S fcron
resolving dependencies...
looking for inter-conflicts...
:: fcron and cronie are in conflict (cron). Remove cronie? [y/N]
$ pacman -S cronie
resolving dependencies...
looking for inter-conflicts...
:: cronie and fcron are in conflict (cron). Remove fcron? [y/N]
Offline
You are both giving examples confirming my point, not refuting it.
Both cronie and fcron provide cron and thus they conflict with each other.
https://projects.archlinux.org/svntogit … ges/cronie
https://projects.archlinux.org/svntogit … ages/fcron
That is a good example. Why cronie's PGKBUILDS has 'cron' in both 'provides' and 'conflicts' while fcron's PKGBUILDS only has 'cron' in 'provides'.
My point is that if you have 'foo' in 'provides', it is not necessary to have it in 'conflicts' too.
Last edited by Gradient (2013-09-17 19:43:17)
Offline
Similarly, packages can conflict with each other, but don't actually provide one and other.
I can't think of any packages off the top of my head, but imagine that package A has /usr/bin/do-a-thing, and package B also has /usr/bin/do-a-thing, each package's do-a-thing does something different, so they don't provide the functionality of the other package, nevertheless, they still conflict with one another.
If the packages both conflicted with one another and also provided the same functionality, it should be sufficient to just declare a common "provides" for the two packages, it's doesn't hurt to keep track of the other package's name in the conflicts array too.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Neither one (cronie, fcron) is in the other's conflicts array, they conflict because they both have cron in the provides and conflicts array.
Conflicts should definitely not imply provides, but I suppose in most cases provides could imply conflicts - but not always.
A case where provides might not imply a conflict is with libraries or interpreters. While it doesn't currently exist, there could - in principle - be a package-name for a general python interpreter for scripts that can run equally well on python2 or python3. Each python2 and python3 could provide the "python-basic" package, but they need not conflict. I don't know if such rare cases actually exist, but I think the flexible mechanism to allow for such cases is good.
Last edited by Trilby (2013-09-17 19:47:28)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
While it doesn't currently exist, there could - in principle - be a package-name for a general python interpreter for scripts that can run equally well on python2 or python3. Each python2 and python3 could provide the "python-basic" package, but they need not conflict. I don't know if such rare cases actually exist, but I think the flexible mechanism to allow for such cases is good.
If 'python2' and 'python3' both have 'python-basic' in their 'provides' array, isn't pacman going to shoot an error if I try to install both?
Offline
You are both giving examples confirming my point, not refuting it.
karol wrote:Both cronie and fcron provide cron and thus they conflict with each other.
https://projects.archlinux.org/svntogit … ges/cronie
https://projects.archlinux.org/svntogit … ages/fcronThat is a good example. Why cronie's PGKBUILDS has 'cron' in both 'provides' and 'conflicts' while fcron's PKGBUILDS only has 'cron' in 'provides'.
I don't know the answer to your question, so I searched around and came up with some examples.
mplayer2 has 'mplayer' in both 'provides' and 'conflicts', but cronie & fcron approch it differently, indeed confirming your point :-)
Offline
I'm confused. If two packages provide the same faux-package, but *don't* list it in the conflicts array, then does pacman remove the other? I hope not.
Edit: I just tested, this works as I expected: if two packages each provide the same name "faux-package" they can both be installed.
I just made pkgbuilds for packages called "crap" and "crap2". They both had "crap-package" in the provides array, but nothing in the conflicts array. They each made a directory in /opt/ but not the same directory so there were no actual file conflicts. Pacman installed both without issue. `pacman -Qs crap-package` returns both installed packages.
Last edited by Trilby (2013-09-17 20:21:10)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I'm confused. If two packages provide the same faux-package, but *don't* list it in the conflicts array, then does pacman remove the other? I hope not.
See for yourself https://bbs.archlinux.org/viewtopic.php … 4#p1325794
Offline
That's not what I was talking about. There they explicitly list cron in the conflicts array. See my test for the real answer.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
There they explicitly list cron in the conflicts array.
Only cronie does, fcron conflicts with dcron, not with cron.
https://projects.archlinux.org/svntogit … ages/fcron
Offline
Yes, but just the same, an explicit conflict is listed in one of the two packages, so they cannot be installed at the same time. The question was if "provides" implies "conflicts" and it does not: two packages with the same "Provides" name can both be installed as long as an explicit "Conflicts" isn't specified. The fact that one can explicitly define the two to be the same is not evidence that the latter is implied by the former.
Last edited by Trilby (2013-09-17 20:26:13)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Yes, but just the same, an explicit conflict is listed in one of the two packages, so they cannot be installed at the same time.
Hm, you're right.
I find these pseudo-reverse conflicts a bit unintuitive but I guess they're simple and get the job done.
Offline
Triby is right. I also did some tests. Marked as solved.
Offline
Hm, interesting! Thanks for clearing that up, Triby.
This topic encouraged me to read the PKGBUILD man page, which provides similar information:
conflicts (array)
An array of packages that will conflict with this package (i.e. they cannot both be
installed at the same time). This directive follows the same format as depends.
Versioned conflicts are supported using the operators as described in depends.
provides (array)
An array of “virtual provisions” this package provides. This allows a package to
provide dependencies other than its own package name. For example, the dcron package
can provide cron, which allows packages to depend on cron rather than dcron OR fcron.
Versioned provisions are also possible, in the name=version format. For example, dcron
can provide cron=2.0 to satisfy the cron>=2.0 dependency of other packages. Provisions
involving the > and < operators are invalid as only specific versions of a package may
be provided.
If the provision name appears to be a library (ends with .so), makepkg will try to
find the library in the built package and append the correct version. Appending the
version yourself disables auto detection.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
When I add the 'libre' repository of Parabola GNU/Linux before all others in 'pacman.conf', pacman asks me to replace linux by linux-libre. I understand that pacman installs the first 'linux' packages it finds. Is pacman looking at the 'provides' array in this case (the two packages' names are different here)?
Offline
No, it's looking at the conflicts array (edit: or perhaps the "replaces")
One can have several kernels installed (I have two) just fine. And while in my case their provides name is different, I also have the linux-ck-headers installed which "provide" linux-headers. I just tested this too for a more realistic example than those above: I can install linux-headers just fine and then I have two packages that "provide" linux-headers, but they do not conflict:
$ pacman -Qs linux-headers
local/linux-ck-core2-headers 3.11.1-2 (ck-core2)
Header files and scripts to build modules for linux-ck. Intel Core2/Newer
Xeon optimized.
local/linux-headers 3.11.1-1
Header files and scripts for building modules for Linux kernel
In the case of the libre repo, I'm assuming it lists the default kernel as a conflict. This would be easily checked with `pacman -Qi linux-libre`.
Last edited by Trilby (2013-09-17 21:39:25)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I don't understand what is happening when I run 'pacman -Syu'. Let's take a simpler example. When I run 'pacman -Syu', pacman asks me if I want to replace 'firefox' with 'iceweasel-libre'.
Here is what I found in the PKGBUILDS of iceweasel :
replaces = ('firefox')
conflicts = ('firefox')
provides = ('firefox')
What is pacman really doing when I run 'pacman -Syu'? Perhaps it looks in the repos for the packages which 'provides' those that I currently have installed, then because of the 'replaces' array, it asks me if I want to replace it by iceweasel-libre? But those are just speculations...
Last edited by Gradient (2013-09-17 21:50:54)
Offline
The conflicts and replaces bits are the ones relevant to your question as I indicated above. Provides is not relevant for this.
As Xyne pointed out in the other thread on this same issue, if the libre repo is before core/extra/community, then pacman will prioritize the libre repo. So it checks for updates to any currently installed package (including firefox) in listed repos starting with libre (if you put it first) and it finds a "new" package that claims to replace firefox, so pacman does as it is told.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
What is pacman really doing when I run 'pacman -Syu'?
pacman reads what packages you have installed and checks if there are newer packages available. If so, downloads and install them along with their dependencies.
Try running
pacman -S firefox
Do you get something like
$ pacman -S cron
:: There are 2 providers available for cron:
:: Repository core
1) cronie
:: Repository community
2) fcron
Enter a number (default=1):
or is iceweasel-libre installed?
Offline
All 4 packages (iceweasel-libre, firefox, cronie, dcron) are not installed and I ran 'pacman -Syy'.
I get this :
$ sudo pacman -S cron
:: There are 2 providers available for cron:
:: Repository core
1) cronie
:: Repository community
2) fcron
Enter a number (default=1):
and
$ sudo pacman -S firefox
resolving dependencies...
looking for inter-conflicts...
Packages (2): mozilla-searchplugins-1.4-2 iceweasel-libre-1:23.0.1.deb1-2
Total Download Size: 21.84 MiB
Total Installed Size: 55.73 MiB
:: Proceed with installation? [Y/n]
Pacman is suggesting 'cronie' and 'fcron' when trying to install 'cron'. I understand this. But now, if I try to install 'firefox', it tries to install 'iceweasel-libre' without mentioning firefox. What is happening?
EDIT : My mistake... I installed pacman-mirrorlist-libre and arch servers are not listed
Last edited by Gradient (2013-09-17 22:29:32)
Offline
Neither cronie nor fcron replaces the other one. If cronie had fcron under "replaces" you'd get similar results as you do with firefox.
It's still the same: pacman is doing what it is told. The package information for iceweasel-libre explicitly says that it replaces firefox. Pacman is *told* to replace firefox. You could request that parabola change how they set these parameters, but as that repo is made to be aggressively Libre-only, then there is no suprise that it is configured to aggresively replace any non-libre software.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline