[pacman-dev] [PATCH] Ensure DESC infolevel is loaded before checking pkg->filename

[Xavier]

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<dan at archlinux.org>
> ---
>
> 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.