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