[pacman-dev] Bug with rxvt-unicode version check
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
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
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?
2007/11/22, Xavier <shiningxc@gmail.com>:
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
On Nov 22, 2007 5:32 AM, Xavier <shiningxc@gmail.com> 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. -Dan
On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:
On Nov 22, 2007 5:32 AM, Xavier <shiningxc@gmail.com> 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 Nov 22, 2007 12:48 PM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:
On Nov 22, 2007 5:32 AM, Xavier <shiningxc@gmail.com> 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. -Dan
On Thu, 22 Nov 2007, Dan McGee wrote:
On Nov 22, 2007 12:48 PM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:
On Nov 22, 2007 5:32 AM, Xavier <shiningxc@gmail.com> 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 22, 2007 10:50 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Nov 22, 2007 12:48 PM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Nov 22, 2007 at 12:37:21PM -0500, Dan McGee wrote:
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 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.
The intention was to "futureproof" the filename changes. Previously, due to the fact that we DID assume the version was in the filename, it was a big chunk of changes to add in the architecture flag. Furthermore, not all potential pacman users will want architectures or even versions in their filenames. Maybe I want my packages just named "pkgname.lol" /me shrugs The whole point of the decoupling is to allow us to remove assumptions and allow us to make changes easier next time. That said: On Dec 25, 2007 12:10 PM, Tobias Kieslich <tobias@justdreams.de> 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.
I have no idea either. Is this error in ONLY the db, or is it in both package metadata AND the db?
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.
On Nov 28, 2007 1:55 AM, Xavier <shiningxc@gmail.com> 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"
participants (5)
-
Aaron Griffin
-
bardo
-
Dan McGee
-
Tobias Kieslich
-
Xavier