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
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
|
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
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.
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.
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).
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?
This is a change, but not something that should be impossible to adjust for.
bug 9162.But you are right, it shouldn't concern too many packages.
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.
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)).
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
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.
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.
provides=('sh')
filesystem:
depends=('sh')
For example, provides=('amule') should be made provides=("amule 2.2.0")?
And what about conflicts?
I assume it remains the same?
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.
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.
> 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..
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.
provides = provname1 provver1
provides = provname2 provver2
The problem is in repo-add. And I don't know about dbscripts.
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
http://archlinux.org/mailman/listinfo/pacman-dev
All you need is an email address and you can keep up on change too.
Thanks.
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
http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=0c5b68877b107f4844f29eb77a9ea5bf7b73fe01
@George_K: The wiki is open for everyone to edit!
Patch attached.
Note: my bash knowledge is limited, so please review it carefully, but it seems to work.
Note: I'm not sure "echo -e" is safe enough.
> 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.
"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?
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]
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
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.