On Thu, Nov 22, 2007 at 11:19:58AM +0100, Xavier wrote:

On Thu, Nov 22, 2007 at 01:45:29AM +0100, bardo wrote:

...

Hi all.

I'm experiencing a strange problem: rxvt-unicode should be upgraded from 8.4-1 to 8.5a-1, but when it comes the time of checking if the package has been cached, 8.4-1 is marked as a match, and gets installed instead of the new version. I can reproduce this whenever I want, since pacman tries to upgrade rxvt-unicode with every -Su.

The relevant part of pacman -Syu --debug is attached, I can upload the whole log if needed (~750KB).

Corrado

This problem already happened. It's not a bug in pacman. It's either an user (well, developer) mistake, or a bug in the repo scripts.

cat /var/lib/pacman/sync/extra/rxvt-unicode-8.5a-1/desc %FILENAME% rxvt-unicode-8.4-1-i686.pkg.tar.gz

Hm. this is not a pacman bug, but maybe pacman could have more sanity checks. Maybe it could check that the FILENAME contains VERSION. In the above case, it was : %VERSION% 8.5a-1 Or once the package has been downloaded, it could also check its .PKGINFO, and see that the version still match. I think the first check should be quite easy, something like strstr(pkg->filename. pkg->version). But I don't know about the second. In any cases. isn't it the repo scripts that should be safer to prevent these problems in the first place?

On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:

On Nov 22, 2007 5:32 AM, Xavier wrote:

...

...

This problem already happened. It's not a bug in pacman. It's either an user (well, developer) mistake, or a bug in the repo scripts.

cat /var/lib/pacman/sync/extra/rxvt-unicode-8.5a-1/desc %FILENAME% rxvt-unicode-8.4-1-i686.pkg.tar.gz

Hm. this is not a pacman bug, but maybe pacman could have more sanity checks. Maybe it could check that the FILENAME contains VERSION.

No, the whole point of the filename field is to decouple the filename from being only based on the package name and version. We just happen to name our files the way we do.

Decoupling it in which goal? Having filename independent from package name and version, or introducing redundancy for more fiability? I'm not suggesting to recompute the filename based on package name and version. Only to check everything is coherent. And if it isn't, just fail. Because, currently, what pacman does is very misleading.

On Thu, 22 Nov 2007, Dan McGee wrote:

On Nov 22, 2007 12:48 PM, Xavier wrote:

...

On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:

...

On Nov 22, 2007 5:32 AM, Xavier wrote:

...

...

This problem already happened. It's not a bug in pacman. It's either an user (well, developer) mistake, or a bug in the repo scripts.

cat /var/lib/pacman/sync/extra/rxvt-unicode-8.5a-1/desc %FILENAME% rxvt-unicode-8.4-1-i686.pkg.tar.gz

Hm. this is not a pacman bug, but maybe pacman could have more sanity checks. Maybe it could check that the FILENAME contains VERSION.

No, the whole point of the filename field is to decouple the filename from being only based on the package name and version. We just happen to name our files the way we do.

Decoupling it in which goal? Having filename independent from package name and version, or introducing redundancy for more fiability?

I'm not suggesting to recompute the filename based on package name and version. Only to check everything is coherent. And if it isn't, just fail. Because, currently, what pacman does is very misleading.

So what if I want to name packages based on their build date? (something like foobar-2007.11.22.pkg.tar.gz.) How would you deal with that?

I guess I don't see the misleading behavior. I see that something broke somewhere, but nothing else. We shouldn't have to do dirty tricks with parsing file names, having every iteration of a package named the same thing should be perfectly acceptable- just ensure your database is generated right. I was following this thread for a while and I'm the one packaging the file. So far I have still no clue where I screwed up and what I did wrong in the process.

-T

On Nov 28, 2007 1:55 AM, Xavier wrote:

On Tue, Dec 25, 2007 at 10:10:49AM -0800, Tobias Kieslich wrote:

...

I was following this thread for a while and I'm the one packaging the file. So far I have still no clue where I screwed up and what I did wrong in the process.

The same thing just happened again with firefox.

...

cat /var/lib/pacman/sync/extra/firefox-2.0.0.10-2/desc %FILENAME% firefox-2.0.0.10-1-i686.pkg.tar.gz

But we probably won't know what happened here either.

I think I do... the -2 file isn't found in our ftp dir. But I *think* that our DB scripts are getting version info from CVS, and not bailing properly. That is, "hey CVS says we should have 2.0.0.10-2, lets build the db... woah file not found, break break break"

2007/11/22, Xavier :

This problem already happened. It's not a bug in pacman. It's either an user (well, developer) mistake, or a bug in the repo scripts.

cat /var/lib/pacman/sync/extra/rxvt-unicode-8.5a-1/desc %FILENAME% rxvt-unicode-8.4-1-i686.pkg.tar.gz

OK, thanks for the explanation. Corrado