Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#9547 - -Sp doesn't print the correct filename

Attached to Project: Pacman
Opened by Xavier (shining) - Tuesday, 12 February 2008, 16:18 GMT
Last edited by Dan McGee (toofishes) - Sunday, 17 February 2008, 01:34 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Low
Priority Normal
Reported Version 3.1.1
Due in Version 3.1.2
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

The packages in community repo don't use the arch suffix.
However, when using -Sp <community package>, the arch suffix appears in the url.

> sudo LANG=C pacman -Sp nexuiz
resolving dependencies...
http://mir.archlinux.fr/community/os/i686/nexuiz-2.3-1-i686.pkg.tar.gz

But the real file is http://mir.archlinux.fr/community/os/i686/nexuiz-2.3-1.pkg.tar.gz

The problem is apparently in alpm_pkg_get_filename (libalpm/package.c)
At least the arch suffix is added there.

But I don't understand why the arch isn't added on "pacman -S nexuiz" operation. In this case,
alpm_pkg_get_filename returns the correct filename. Apparently, when this function is called during a -S operation,
pkg->filename is already built, and so alpm_pkg_get_filename simply returns it.
But in the case of a -Sp operation, this is not the case, and a wrong filename is built and returned by alpm_pkg_get_filename.
This task depends upon

Closed by  Dan McGee (toofishes)
Sunday, 17 February 2008, 01:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with commit b206aaee881abd6e256428f2146212cfc1c69be2
Comment by Xavier (shining) - Wednesday, 13 February 2008, 18:17 GMT
alpm_pkg_get_filename doesn't use the FILENAME field from the sync db.
That's probably because this field didn't exist originally, it was apparently added with 3.0 :
http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=986409f9bd7b84e63352b9ec1f825b0c917627a6#patch3

So I guess there was a transition period where this new filename field could not be used to stay backward compatible with old database.
Since this appeared in 3.0, and we are now at 3.1, I think it's safe to assume the filename field is present now.
Especially because the way filename are re-computed is totally bogus, and doesn't work with any database.

The get_filename function returns "name-version(-arch).pkgext"
It only uses arch when it's available. However, arch field is not available in core/extra database, but the arch does appear in the filename.

egrep -A1 "FILENAME|ARCH" /var/lib/pacman/sync/extra/rxvt-unicode-9.02-1/desc
%FILENAME%
rxvt-unicode-9.02-1-i686.pkg.tar.gz

So here, the filename constructed (the one printed by Sp) is rxvt-unicode-9.02-1.pkg.tar.gz , which is wrong.

And with the community database, it's the opposite : the arch field is in the db, but doesn't appear in the filename! So it's broken here too.

egrep -A1 "FILENAME|ARCH" /var/lib/pacman/sync/community/nexuiz-2.3-1/desc
%FILENAME%
nexuiz-2.3-1.pkg.tar.gz
--
%ARCH%
i686

And get_filename returns nexuiz-2.3-1-i686.pkg.tar.gz

This problem only shows up on -Sp operation and not -S, because during an -S operation, the package metainfo are loaded with the DESC level before get_filename is called.
And the DESC level is likely required because the frontend prints the package size before starting the download / installation. So there is nothing broken / strange here.

To sum up, it's not possible to guess the filename field from the name, version and arch fields, so this bogus code should be simply removed, since we can use the filename field from the db directly now, and everything will be fine :)
Comment by Xavier (shining) - Friday, 15 February 2008, 16:25 GMT
This was further discussed on the ML, and finally, the filename field can't be always used, since it's not always present (there are still many old db entries without it) :
http://www.archlinux.org/pipermail/pacman-dev/2008-February/011136.html

So a more conservative fix was included for 3.1.2 :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=b206aaee881abd6e256428f2146212cfc1c69be2

If we really want to totally clean this, we would need to regenerate all official databases (core,extra,testing,unstable) so that all entries include the filename field.
I'm not sure how to proceed with this however. Dan or Aaron ?
Comment by Dan McGee (toofishes) - Sunday, 17 February 2008, 01:34 GMT
  • Field changed: Due in Version (Undecided → 3.1.2)
Xavier, you know my position on the "official" DBs. :)

Marking this as a 3.1.2 bug, and we know the actions we need to take to further resolve it, so we'll handle those on the ML.

Loading...