[aur-general] Versioned Provisions
This is a little "heads up" email to all the package maintainers out there. Pacman 3.1 has support for versioned provisions. But what this also means is that there's going to be some breakages in packages. Let me explain by way of example: package foo depends=(bar>=1.2) package omg provides=(bar) In the past, you could install both foo and omg at the same time and everything would be satisfied. Not now. Now, the provision of "omg" will fail, because it's not providing the right version. What does this mean? Well, a few things. First and foremost, versioned provisions are a little broken in 3.1.0, but 3.1.1 will fix all this py allowing you to say: provides=(bar=1.2) Did I get this right? Dan, Xavier?
Aaron Griffin wrote:
This is a little "heads up" email to all the package maintainers out there.
Pacman 3.1 has support for versioned provisions. But what this also means is that there's going to be some breakages in packages.
Let me explain by way of example:
package foo depends=(bar>=1.2) package omg provides=(bar)
In the past, you could install both foo and omg at the same time and everything would be satisfied. Not now. Now, the provision of "omg" will fail, because it's not providing the right version.
What does this mean? Well, a few things. First and foremost, versioned provisions are a little broken in 3.1.0, but 3.1.1 will fix all this py allowing you to say: provides=(bar=1.2)
Did I get this right? Dan, Xavier?
Yes, I only want to clarify that packagers need to wait for 3.1.1 to be released before starting to update their packages. And this feature is useful because in the above case, omg package could be at version 0.1. pacman 3.0 deduced from this that omg package provided bar-0.1 But there was no way to specify that omg actually provided bar-1.2, and thus satisfied the bar>=1.2 dependency of foo package. There is one point that wasn't appreciated by several people though. When no provision version is specified, pacman no longer defaults to the package version. Why? Consider for example in the above case that the package omg is at version 2.0, but doesn't provide 1.2 version of bar, only 1.0. With the old behavior, pacman would still accept to install omg package as a dependency of foo, which would result in a broken system. Finally, there are quite a few cases where the package version and the provision version are not related. You can have a look at all provides lines in the /var/abs tree : find /var/abs -name PKGBUILD | xargs egrep '^provides|^pkgname|^pkgver' |grep provides -B2 First, there are virtual provisions, like sh, cron, smtp-server. But there are other good candidates, here are a few ones: nvidia-utils and fglrx-utils provide libgl avahi provides howl and mdnsresponder python provides python-ctypes gamin provides fam etc... And then consider all the devel packages (cvs, svn, etc).
On Jan 17, 2008 3:49 PM, Xavier
Aaron Griffin wrote:
This is a little "heads up" email to all the package maintainers out there.
Pacman 3.1 has support for versioned provisions. But what this also means is that there's going to be some breakages in packages.
In addition to all else that was said, I will offer the following. In 3.1.0, you may have heard or read that the provisions format was like this: provides=('cairo 1.1') 3.1.1 will change it to this: provides=('cairo=1.1') The reason for the switch came down to two things- an error in repo-add dealing with the space, and the issue that packagers would forget the quotes on their provision (even Aaron did it above!). If we use the = instead of a ' ' (space), we can avoid these two issues. What this does *NOT* mean is that versioned provisions will ever be supported. This is the reason we did not go with the = sign originally- it might lead packagers to believe they were supported. Versioned provisions really don't make sense- if someone can provide a use case, I can probably debunk it. -Dan
Dan McGee wrote:
What this does *NOT* mean is that versioned provisions will ever be supported. This is the reason we did not go with the = sign originally- it might lead packagers to believe they were supported. Versioned provisions really don't make sense- if someone can provide a use case, I can probably debunk it.
Just to clarify, what Dan meant here is that the only supported operator is = (no >=, <=, >, <).
Dan McGee wrote:
What this does *NOT* mean is that versioned provisions will ever be supported. This is the reason we did not go with the = sign originally- it might lead packagers to believe they were supported. Versioned provisions really don't make sense- if someone can provide a use case, I can probably debunk it.
On Jan 17, 2008 6:19 PM, Xavier
Just to clarify, what Dan meant here is that the only supported operator is = (no >=, <=, >, <).
On Jan 17, 2008 6:19 PM, Aaron Griffin
Um, I think you misspoke a little here. I assume you meant to add something other than "versioned provisions will ever be supported". I'd guess, based on context, you meant to indicate the ">=" and "<=" stuff, right?
Err...sorry guys! Aaron and Xavier are completely correct here. I meant to say that versioned *operators* are not supported if that makes any more sense, or in easier terms, <=, >=, <, and < are not supported. Thanks for catching this. -Dan
On Jan 17, 2008 5:50 PM, Dan McGee
forget the quotes on their provision (even Aaron did it above!). If we
Hah, but I know bash parsing rules!
What this does *NOT* mean is that versioned provisions will ever be supported. This is the reason we did not go with the = sign originally- it might lead packagers to believe they were supported. Versioned provisions really don't make sense- if someone can provide a use case, I can probably debunk it.
Um, I think you misspoke a little here. I assume you meant to add something other than "versioned provisions will ever be supported". I'd guess, based on context, you meant to indicate the ">=" and "<=" stuff, right?
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Xavier