Dan McGee wrote:
This is the first step of fixing FS#9547. This should not break any existing code that may rely on this function behaving the way it did, and should be good for inclusion in a maint release.
In addition, update pactest so it fills the FILENAME field in the DB entries it creates so we can move forward with a real fix to this issue.
Signed-off-by: Dan McGee
--- How about this for a maint release fix? Then we can further evaluate if necessary for either 3.1.3 or 3.2.0. Of course, if we can address all of the issues I brought up in my last email regarding your patch, then we can try and fully fix the problem in 3.1.2. This just seems like a safer road to take when we aren't going to be able to get a lot of testing in.
Actually, my patch is not acceptable. I totally overlooked a really crap fact : there are a HUGE number of packages without the FILENAME field in the databases (not community, but all others) find /var/lib/pacman/sync/ -name desc | wc -l 4274 grep -r FILENAME /var/lib/pacman/sync/ | wc -l 3376 900 packages without it. Let's look at one of these : /var/lib/pacman/sync/unstable/at76c503a-cvs-20061223-1/desc In that desc file, we have NAME and VERSION, but not ARCH, so the filename generated is : at76c503a-cvs-20061223-1.pkg.tar.gz And actually, that's the real filename which exists on the mirrors. So we have two kind of entries : entries without filenames (their real filenames don't have the -arch suffix) and entries with filenames (which have the -arch suffix). So the current filename fallback can't be removed at all. It actually works for the entries without filenames, and there are a lot of them . The only correct way for dealing with this is exactly what your patch does. First load the desc level, then use the filename field if it exists. Otherwise fallback.