FS#34446 - [gammu] Can't upgrade from gammu 1.32.0-1 to 1.32.0-2 due to file conflicts

Attached to Project: Community Packages
Opened by Wieland Hoffmann (Mineo) - Sunday, 24 March 2013, 18:15 GMT
Last edited by Ray Rashif (schivmeister) - Tuesday, 26 March 2013, 15:12 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ray Rashif (schivmeister)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
I *suspect* this is because the shared libraries were moved from /usr/lib to /usr/lib64 (which is just a symlink to /usr/lib) and pacman doesn't deal with the symlink.

Additional info:
* package version(s) 1.32.01-1 (installed), 1.32.0-2 (to be installed)

Steps to reproduce:
have gammu 1.32.0-1 installed
update your system

LC_ALL=en_US.utf-8 sudo pacman -Su (note: I did -Syu just before that but restarted with only -Su to get english messages)
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
[targets omitted...]
Total Installed Size: 1934.79 MiB
Net Upgrade Size: 56.30 MiB

Proceed with installation? [Y/n] y
(128/128) checking package integrity [------------------------------------------] 100%
(128/128) loading package files [------------------------------------------] 100%
(128/128) checking for file conflicts [------------------------------------------] 100%
error: failed to commit transaction (conflicting files)
gammu: /usr/lib64/libGammu.so exists in filesystem
gammu: /usr/lib64/libGammu.so.7 exists in filesystem
gammu: /usr/lib64/libgsmsd.so exists in filesystem
gammu: /usr/lib64/libgsmsd.so.7 exists in filesystem
Errors occurred, no packages were upgraded.
This task depends upon

Closed by  Ray Rashif (schivmeister)
Tuesday, 26 March 2013, 15:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  1.32.0-3
Comment by ybsar (ybsar) - Tuesday, 26 March 2013, 06:31 GMT
The package is fine but lately follows the change from /lib to /usr/lib. It exactly results in the issue announced in January.

gammu change:
https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/gammu&id=0282e84135d1013e67be7330cad47b6aab2a4e53

filesystem change:
https://www.archlinux.org/news/update-filesystem-201301-1-and-glibc-217-2-together/

1. backup and remove files /usr/lib64/lib{Gammu,gsmsd}.so*
2. update gammu package
Comment by Wieland Hoffmann (Mineo) - Tuesday, 26 March 2013, 08:51 GMT
The announcement clearly says "All Arch Linux packages that had files in this directory [/usr/lib64] have been updated, so update these individually first." but this package version is actually the first to have files in /usr/lib64.
Comment by Denis Kasak (dkasak) - Tuesday, 26 March 2013, 11:50 GMT
I stumbled upon this too today. I don't think gammu should be installing to /usr/lib64 and the changes to its PKGBUILD don't reflect that this was intended in any way. Notice the addition of this line:

+ -DCMAKE_INSTALL_LIBDIR=/usr/lib

It seems like it's a CMake bug or something related.
Comment by Ray Rashif (schivmeister) - Tuesday, 26 March 2013, 13:40 GMT
  • Field changed: Category (Packages: Testing → Packages)
  • Field changed: Architecture (All → x86_64)
The lib64 dir exists only in -2 now, for some reason (in -1 it was usr/lib as usual). The source has not changed (it is still the same version), and the build system remains unchanged as well, but our symlink/lib transition may be confusing it.

edit: It is because lib64 now exists (albeit as a symlink) and gammu explicitly checks for that and as a result makes its own decision to use it. There doesn't seem to be any built-in override but I'll look. The last packager probably forgot to verify whether INSTALL_LIBDIR was valid (it's not, in this case).

edit2: There _is_ an override, fortunately, in the form of a 'LIB_SUFFIX'. Fix rolling soon for those who have refrained from forcing the update :)

Loading...