Pacman puzzle

Hi,

As a Manjaro newbie (not a linux one), one of the fist thing I did was try to understand how pacman works. I thought I'd got it... until today. Can someone explain what is going on ?

Ok, so first I do a sudo pacman -Syy, just to be sure. Then look at this :

1 sudo pacman -Qs python2-pillow returns nothing. This means that this package is not installed.
2 ls -l /var/cache/pacman/pkg | grep python2-pillow returns nothing. The package is not in my cache.
3 pacman -Ss python2-pillow returns a package python2-pillow6 (community/python2-pillow6 6.2.1-1 to be precise). That means that there is no python2-pillow package in the repository.
4 And this is what I don't understand : sudo pacman -S python2-pillow wants to install python2-pillow6 !

Now I am aware of package groups, of meta packages (does that notion exist in pacman ?) but that is something new to me. Some kind of alias ? But then, how does one finds them ? And isn't it weird that some name aliases to a conflicting package ?

Just to be clear, my question is entirely about the way pacman and repositories work. I don't care at all about python2-pillow !

I find it even more puzzling because python2-pillow and python2-pillow6 are meant to be different packages (as of now, the first one is listed in the conflicting packages of python2-pillow6 – see pacman -Si python2-pillow6). And indeed, still a few hours ago, I had python2-pillow installed and not python2-pillow6.

So if anyone can explain how that works internally...

in the package there is a field called "provide" and in package python2-pillow6 this field say it provide python2-pillow

Provides: python2-imaging, python2-pillow, python-imaging

then there can be more than one package that provide the same "function" and then they often conflict.
When you do a search with pacman it also check in the "provide" field to find packages.

I hope to be clear.

other expemple is the package dkms it depend on linux-headers
there is no linux-headers package.. all linuxXX-headers packages provide linux-headers but in this case they don't conflict each others as they can be installed side by side.. but at least one need to be installed to satisfy the dependency for dkms.

the "provide" can be a pseudo-package name that does not exist physicaly

1 Like

Thanks, I had somehow failed to see that Provides line.

Logically, wanting to install the provided package installs the provider.
Perfect.

(Well, I still find it weird that python2-pillow6 can both provide and conflict with python2-pillow but I'll learn to deal with it :thinking:)

yes... if there was both packages python2-pillow and python2-pillow6 at some time.. if you installed python2-pillow6 it have to conflict with real python2-pillow otherwise they would override files of the others..
pacman don't see as conflict if the provide and conflict is from the same package.

For the record, running pacman -Syy and then installing a single package is not a good idea. This will leave your system in a partial upgrade state. Make sure that your system is updated as whole before installing any single package:
sudo pacman -Syu
or if there has been some changes to your mirrors:
sudo pacman -Syyu

As of version 7, python-pillow dropped Python 2 support. Some applications may still need version 6, so that's why python-pillow6 & python2-pillow6 were created.

Yes of course. Thanks for reminding that to everyone who might come reading this.

But surely you understand that this command (in my post) was not about installing anything but about checking if a package was in the repository or not. Unless there is something else that I do not understand, this command sudo pacman -Syy was just what was needed for that.

It was just there to say "Hey look, my database is indeed synchronized with the repository on the mirror so if a search for a package returns nothing then it can be deduced that the package does not exist on the mirror". Isn't that correct ?

1 Like

The wiki is your friend here.

No.

-y, --refresh
Download a fresh copy of the master package database from the server(s) defined in
pacman.conf(5). This should typically be used each time you use --sysupgrade or -u. Passing
two --refresh or -y flags will force a refresh of all package databases,
even if they
appear to be up-to-date.

Doesn't that make the following statement true:

"Hey look, my database is indeed synchronized with the repository on the mirror so if a search for a package returns nothing then it can be deduced that the package does not exist on the mirror"

Or should one use pacman -Si PACKAGE

-i, --info
Display information on a given sync database package. Passing two --info or -i flags will
also display those packages in all repositories that depend on this package.

Edit: @merlock, I should have payed more attention to the ArchWiki quote and man pacman.

pacman -Si PACKAGE

seems to be the answer to my question.

@Marte, I'll bend a little, but with a caveat: @Shadoko's deduction is correct, only at the time of the sync.

Depending on how the mirror is set up to get upstream changes, it could change by the minute.

:slight_smile:

1 Like

Thanks again.
As I've said before, I am learning how pacman works and even though I find it a little disconcerting, I'll deal with it. I am glad that you pointed those reasons to me.

Anyway, let me explain why I find it strange.

We here have a package B (python2-pilow6) and a package C (python2-pillow) that cannot be installed together. Up to not so long ago (last update if I am correct), both existed in the repository (hence the conflict).

Now, package C doesn't exist anymore, not as a 'real' package anyway.
It has been superseded by package B that serves more or less the same purpose.

Then what might be the point of saying that B provides C ?
The only answer that I can find is that there are other packages, let A be one of them, that depend on C. If that is the case, I would expect to have the dependencies of A changed to B rather than a messy A depends on C that is provided by B that conflicts with C. Guess that would be slightly more work though (I expect there are many such A's).

Anyway, that's not how it's done here. I'm fine with that, just learning.

If I may ask a last question...

How does pacman deal with a situation where two packages B and C provide more or less the same functionality and another package A needs that functionality. Does the maintainer of A makes a choice ? For example he arbitrarily decides that A will depend on B ; and if the maintainer of C agrees he could decides that C provides B (allowing for A and C to be installed without B). Such a situation could be a case where C provides B and conflicts with B.

Yet it would be simpler if A depended on B|C ('B or C') but does such a notion of 'alternative dependency' exists in pacman ?'

I understand your puzzles are of "classroom" type.
I would suggest using another method to ask.
Open the book (Archwiki) on the subject of your choice and point the part of text (quoted) that you cannot understand.

That makes all being at the... same page.

BTW you are a fruitful student :grin:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by