Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#9171 - Dependency problem in new Pacman

Attached to Project: Pacman
Opened by Patrick Bartels (p4ddY) - Saturday, 12 January 2008, 10:35 GMT
Last edited by Dan McGee (toofishes) - Sunday, 20 January 2008, 20:44 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Xavier (shining)
Dan McGee (toofishes)
Architecture All
Severity High
Priority Normal
Reported Version 3.1.0
Due in Version 3.1.1
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
When trying to install a package, which depends on a certain version of a package that is provided by another one (for example its SVN version) then it fails in Pacman 3.1.0.
This affects a lot of packages including kdemod, kdemod4 (depends on qt>=4.3.3-1 which is provided by qtmod) and a few of my packages for the zen-kernel (they depend on 2.6.24.rc2.zen0-1 that is provided by kernel26zen-git)

Details:
self.description = "Broken in Pacman 3.1.0"

p1 = pmpkg("backend", "0.5-1")

p2 = pmpkg("backend-svn", "0.6-1")
p2.conflicts = ["backend"]
p2.provides = ["backend"]

p3 = pmpkg("frontend")
p3.depends = ["backend>=0.1-1"] # without >=0.1-1 it works

for p in p1, p2, p3:
self.addpkg2db("sync", p)

self.args = "-S %s" % " ".join([p.name for p in p2, p3])

self.addrule("PACMAN_RETCODE=0")
This task depends upon

This task blocks these from closing
 FS#9233 - Dependancy problem with totem-plugin  
Closed by  Dan McGee (toofishes)
Sunday, 20 January 2008, 20:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 3.1.1, versioned provisions now use '=' instead of ' ' (space). Please update your PKGBUILDs accordingly.
Comment by Nagy Gabor (combo) - Saturday, 12 January 2008, 10:47 GMT
Well, we expected these kind of reports... This is not a bug, this is a feature;-)

In 3.1.0 versioned provisions were introduced. So you can say provides = ["backend 0.6-1"] or ["backend 0.6"] or any appropriate version, and then the dependency of p3 will be satisfied.

The old pacman used the package version as the provision version, which could lead some false decisions.

Some background: we cannot modify packages to the new provision scheme until users don't change to the new pacman (i.e. it appears in core).
Comment by Patrick Bartels (p4ddY) - Saturday, 12 January 2008, 11:04 GMT
Sounds nice, thank you :)
Comment by Xavier (shining) - Saturday, 12 January 2008, 11:49 GMT
I think the main thing to do here is just warning the maintainers of these packages (kdemod, kdemod-kernel and kernel26zen-git) of these issues,
so thay they can fix it as fast as possible when pacman 3.1 is moved to core.
Probably several other packages are concerned, but not sure how many. Currently, only unofficial packages were found having this problem.
So maybe this bug report is good enough as a reference for future problems?
Comment by Dan McGee (toofishes) - Saturday, 12 January 2008, 17:23 GMT
Realize that in this bug report, only two packages need changing- qtmod and kernel26zen-git.

This is a change, but not something that should be impossible to adjust for.
Comment by Xavier (shining) - Saturday, 12 January 2008, 17:33 GMT
There is also cairo-lcd. see  bug 9162 .
But you are right, it shouldn't concern too many packages.
Comment by Orivej Desh (George_K) - Saturday, 12 January 2008, 22:40 GMT
Not sure if this is the right place to report, but since pacman 3.1 is in core, testing/qt must provide "qt4 a.b.c-d" instead of "qt4".
Comment by Dan McGee (toofishes) - Saturday, 12 January 2008, 23:03 GMT
No need for that full of a version- simply providing "qt4 4.2" or whatever is good enough. A pkgrel is overkill.
Comment by Thomas Bächler (brain0) - Sunday, 13 January 2008, 13:13 GMT
Still, for backwards compatibility, provides=(foo) should be equivalent to provides=(foo=$pkgver), IMO this is intuitive behaviour.
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 16:13 GMT
Well, I like the new behavior better:
In the examples above provides=(foo $pkgver) ('=' is NOT needed) may be intuitive but don't forget about "rarian provides scrollkeeper", "util-linux-ng provides util-linux"... examples neither.
I don't know whether the old behavior is acceptable here or not; but personally I'm trust on our packagers' decision better than on pacman's [util-linux>=1.2.3 is quite a _specific_ request, isn't it?].

And you can easily add $pkgver to your provision if needed, so imho 3.1.0 gives more freedom to the packager.
Comment by Thomas Bächler (brain0) - Sunday, 13 January 2008, 16:24 GMT
It wouldn't remove any freedom to add $pkgver as a default, if no version is specified in the provides array, but it would ensure backward-compatibility. Also, most of the time one will have to write provides=("foo $pkgver"), as it makes sense in most cases.
Alone the fact that it immediately introduced problems in the Archlinux community shows that this default behaviour is also necessary.

On another note, the notation without the '=' sign is inconsistent with the notation in the depends array, IMO they should be consistent. It is also weird if one has several entries in the provides array (like provides=("foo 1.2" "bar 2.0") instead of provides=(foo=1.2 bar=2.0)).
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 17:02 GMT
"It wouldn't remove any freedom to add $pkgver as a default,"
It would, that's what I tried to explain. I would remove the option to indicate that this package provide "provision" but NOT "provision $pkgver".

About the '=': http://www.archlinux.org/pipermail/pacman-dev/2007-November/010172.html
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 17:07 GMT
'I would remove' -> 'It would remove'
Comment by Dan McGee (toofishes) - Sunday, 13 January 2008, 17:13 GMT
Here is the deal. This was discussed for a decent amount of time on the pacman-dev mailing list. Anyone is welcome to join that list. Nagy's link above is just one of the many emails on this subject.

I know not everyone can follow development of everything we do, but at the same time, you have to respect some of the decisions our team made if you are not there to comment on them. This was a decision we made. Sure, it is not backwards compatible, but in the big scheme of things, this affects a rather small number of packages, and is nothing that a simple rebuild can't address.
Comment by Manuel C. (ekerazha) - Sunday, 13 January 2008, 17:13 GMT
I agree to brain0
Comment by Thomas Bächler (brain0) - Sunday, 13 January 2008, 17:23 GMT
Nagy, name a case where a package provides another package but no version of it. This does not happen. As I mentioned before, the normal case will be that you want to provide the exact same version that you see in $pkgver. The case where you want a different version is a corner case.

I cannot find any reason in the post you pointed me to about the =, can you point me to a specific passage? In any way, it does not make any sense to have a completely different notation for versioned provides and versioned depends.
Comment by Dan McGee (toofishes) - Sunday, 13 January 2008, 17:37 GMT
bash:
provides=('sh')

filesystem:
depends=('sh')
Comment by (N/A) (wantilles) - Sunday, 13 January 2008, 17:54 GMT
So which is the correct syntax now?

For example, provides=('amule') should be made provides=("amule 2.2.0")?

And what about conflicts?

I assume it remains the same?
Comment by Nagy Gabor (combo) - Sunday, 13 January 2008, 18:00 GMT
"I cannot find any reason in the post you pointed me to about the =,"
Provision is not a dependency, it is a (povisionname,provisionver) pair (provisionver may be missing), so can define 'equivalent with' or 'virtual' packages. And I think you don't refer to real packages as audacious-player=1.4.2-1 neither.

But come on, this is just a syntax discussion.
I referred to that post to show that your preferred '=' version was also mentioned on ML, but was dropped.
Comment by Dan McGee (toofishes) - Sunday, 13 January 2008, 18:04 GMT
Nothing has changed except provisions syntax.

Here is how it now works, as clear as I can put it (using your example above).
If there are packages that depend on a certain version of amule, then anything that provides amule must specify a version number. Your syntax above is correct. provides=('amule 2.2.0') will do the job too.

If packages depend on amule but versions are never specified, then provides=('amule') will do the job just fine.

The reasoning is this- if a package is specific enough in its depends array for a certain version of amule, then pacman can not assume that anything that provides amule is good enough to satisfy this dependency. Unfortunately this behavior has been badly broken in the past, causing all this controversy here. Before, pacman would have looked at the version of your amule-ng package or whatever and used that to decide, which is not at all what one would expect.
Comment by Xavier (shining) - Monday, 14 January 2008, 18:42 GMT
> On another note, the notation without the '=' sign is inconsistent with the notation in the depends array, IMO they should be consistent.
> It is also weird if one has several entries in the provides array (like provides=("foo 1.2" "bar 2.0") instead of provides=(foo=1.2 bar=2.0)).

The thing is, an operator for a provision version doesn't make much sense. The provision is there for replacing pkgver, so it has the same status as pkgver.
It's a simple version, without operators.
Putting this another way, say we have the following depends : amule>=2.0
To see if a package satisfy this dependency, we first check if pkgname == amule. And then if pkgver >= 2.0
If not, we looks at the package provisions : we then check if provname == amule, And then if provver >= 2.0

I hope you see that it's consistent here.

Now, where you have a very valid point is that the current syntax is broken...
A versioned provisions ends up like this in the .PKGINFO :
provides = provname provver

Then, when we add it to the db, it becomes this :
%PROVIDES%
provname
provver

So in .PKGINFO, we are using a space both for separating provisions, and for separating the name from the version..
Comment by Aaron Griffin (phrakture) - Monday, 14 January 2008, 18:44 GMT
As a suggestion, it might be worthwhile to force a '=' in the providion in the PKGBUILD. Do we split the provisions as if it were a dep?
Comment by Xavier (shining) - Monday, 14 January 2008, 18:50 GMT
No, we don't, we just do it manually, in libalpm/deps.c :
344 >->-char *provver = strchr(provname, ' ');

So changing it to = is a trivial change. But then, people might think we handle provisions like deps,
and try something like : provides=(foo>=1.2) , which would break pacman.

That would still be better than the current situation which doesn't work though.
Comment by Xavier (shining) - Monday, 14 January 2008, 19:41 GMT
Correction to what I said above. makepkg and .PKGINFO are fine, here is what happens with multiples provisions :
provides = provname1 provver1
provides = provname2 provver2

The problem is in repo-add. And I don't know about dbscripts.
Comment by Jan M. (funkyou) - Monday, 14 January 2008, 22:28 GMT
Ok, after chatting with shining i just understood why versioned provisions are a good thing

BUT

_please_ provide a wiki page or something and a message in the install file when changing the PKGBUILD syntax, so packagers know what has been changed... This time i was completely on my own and had to search a lot until i got these issues solved and adapt the PKGBUILDs...

Thanks

Jan
Comment by Aaron Griffin (phrakture) - Monday, 14 January 2008, 23:12 GMT
That's my fault. It's hard to find the pacman-dev mailing list.
http://archlinux.org/mailman/listinfo/pacman-dev

All you need is an email address and you can keep up on change too.
Comment by Dan McGee (toofishes) - Monday, 14 January 2008, 23:18 GMT
You seem to understand the concept quite well now, and the wiki is open to anyone to edit. Can you document the stuff you understand and the rest of us can go back and modify it if necessary?

Thanks.
Comment by Jan M. (funkyou) - Tuesday, 15 January 2008, 00:08 GMT
Sorry, i didnt expect to search through the pacman-dev ML for an update on building packages. As said, a warning in the install message would be very useful when the PKGBUILD syntax got changed...

I have edited the wiki entry to reflect this change, its not complete and has no further explanation but should be ok for now:

http://wiki.archlinux.org/index.php/The_Arch_package_making_HOW-TO_-_with_guidelines
Comment by Orivej Desh (George_K) - Tuesday, 15 January 2008, 06:36 GMT
I think pkgrel there must become pkgver. And the possibility of specifying pkgrel should be documented too.
Comment by Dan McGee (toofishes) - Tuesday, 15 January 2008, 06:38 GMT
We've made a patch that will be in the 3.1.1 release. See the following commit for details.

http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=0c5b68877b107f4844f29eb77a9ea5bf7b73fe01

@George_K: The wiki is open for everyone to edit!
Comment by Manuel C. (ekerazha) - Tuesday, 15 January 2008, 10:30 GMT
What about obsolete software? I can't say Pidgin 2.3.1 provides Gaim 2.3.1 because it doesn't exist and I can't say it provides Gaim 1.4 because that's just untrue. So we can't specify a correct provision version in these situations.
Comment by Nagy Gabor (combo) - Tuesday, 15 January 2008, 10:52 GMT
Dan, fixing repo-add is much more easier than expected.
Patch attached.
Note: my bash knowledge is limited, so please review it carefully, but it seems to work.
Comment by Nagy Gabor (combo) - Tuesday, 15 January 2008, 10:57 GMT
So if I wasn't clear, the previous patch assumes that we keep the old "provision provver" format.
Note: I'm not sure "echo -e" is safe enough.
Comment by Nagy Gabor (combo) - Tuesday, 15 January 2008, 11:01 GMT
Note2: or we can use new RARE delimiter, and then we can keep the old "tr -s '$DELIMITER' '\n'" too.
Comment by Xavier (shining) - Tuesday, 15 January 2008, 11:02 GMT
> What about obsolete software? I can't say Pidgin 2.3.1 provides Gaim 2.3.1 because it doesn't exist
> and I can't say it provides Gaim 1.4 because that's just untrue.
> So we can't specify a correct provision version in these situations.

Actually, that's exactly the point. If you can't specify a version, then don't.
And in this case, pacman will no longer assume that pidgin provides gaim 2.3.1.
It will simply provide gaim, without any specific version.

But well, you also to need to think about the packages depending on gaim.
If they simply had depends=(gaim), then you don't have to worry about it.
If they had depends=(gaim>=1.4), then you have to decide if pidgin provides this or not.
Maybe it does, in that case, specify a provision version.

Anyway, that case might be silly, are there still any packages that depend on gaim?
If not, you don't have to worry about it either.
Comment by Xavier (shining) - Tuesday, 15 January 2008, 11:04 GMT
Nagy, did you see Dan's comment in the git log :

"Keeping the ' ' based
format would have required us to do special parsing in repo-add, as well as
being susceptible to users not using quotes in their provides array."

If an user forgot to put quotes when specifying a version, things would still break.
And what about dbscripts?
Comment by Nagy Gabor (combo) - Tuesday, 15 January 2008, 11:10 GMT
Manuel: this is your decision.
If Gaim 1.4 is the latest version then provision "Gaim 2.3.1" indicates that your pidgin is later than any gaim version, so will satisfy all rational gaim>=ver dependency.

Note: Consider the theoretical case, when Gaim dies with 1.4, and Pidgin is born with 0.1; this is the case where the power of versioned provision is needed ["pidgin 0.1" provides "gaim 1.5" for example]
Comment by Nagy Gabor (combo) - Tuesday, 15 January 2008, 11:16 GMT
"If an user forgot to put quotes when specifying a version, things would still break."
Well, as I told you yesterday, imho this is not an issue.
I've chosen the last PKGBUILD from aur for example: http://aur.archlinux.org/packages/make_e17/make_e17/PKGBUILD
<- everything is quoted here.

I didn't said that ' ' is better than '=', I just wanted to avoid the syntax change.

dbscripts: needs testing :-P
Comment by Roman Kyrylych (Romashka) - Tuesday, 15 January 2008, 16:49 GMT
With ' ' and '=' causing problems - why can't we use something like ':' (I hope bash will allow pkg:ver unquoted)?
Comment by Dan McGee (toofishes) - Tuesday, 15 January 2008, 16:55 GMT
There are no problems with '=' besides that it makes people think of depends syntax, and they may be tempted to use <= or >=, which will not work.

Using ':' or ';' or '%' or any other symbol would probably create just as much confusion, because it would be another not so obvious syntax.

'=' has been discussed, decided on by Nagy, Xaver and I, and I think it is an acceptable solution to the original issue with bash parsing. This patch has been pushed to maint and I don't see another change occurring unless some huge problem comes of it.
Comment by Roman Kyrylych (Romashka) - Tuesday, 15 January 2008, 16:56 GMT
ok then

Loading...