Arch Linux

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).

Sounds nice, thank you :)

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?

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.

There is also cairo-lcd. see  bug 9162 .
But you are right, it shouldn't concern too many packages.

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".

No need for that full of a version- simply providing "qt4 4.2" or whatever is good enough. A pkgrel is overkill.

Still, for backwards compatibility, provides=(foo) should be equivalent to provides=(foo=$pkgver), IMO this is intuitive behaviour.

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.

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)).

"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

'I would remove' -> 'It would remove'

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.

I agree to brain0

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.

bash:
provides=('sh')

filesystem:
depends=('sh')

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?

"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.

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.

> 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..

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?

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.

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.

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

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.

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.

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

I think pkgrel there must become pkgver. And the possibility of specifying pkgrel should be documented too.

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!

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.

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.

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.

Note2: or we can use new RARE delimiter, and then we can keep the old "tr -s '$DELIMITER' '\n'" too.

> 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.

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?

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]

"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

With ' ' and '=' causing problems - why can't we use something like ':' (I hope bash will allow pkg:ver unquoted)?

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.

ok then