Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#20320 - lib32-glibc package 2.12-5 file/dir conflicts

Attached to Project: Community Packages
Opened by Milena (Milena) - Friday, 30 July 2010, 00:22 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 28 August 2010, 08:56 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description: lib32-glibc includes a symlink in /opt/lib32/usr: "include" the link target is /usr/include. A folder "include" does already exist in /opt/lib32/usr and contains several files from other packages. Pacman upgrade error:


looking for inter-conflicts...

Targets (1): lib32-glibc-2.12-5

Total Download Size: 0.00 MB
Total Installed Size: 12.58 MB

Proceed with installation? [Y/n] y
checking package integrity...
(1/1) checking for file conflicts [######################] 100%
error: failed to commit transaction (conflicting files)
lib32-glibc: /opt/lib32/usr/include exists in filesystem
Errors occurred, no packages were upgraded.



Additional info:
* package version(s)

lib32-glibc-2.12-5

* config and/or log files etc.

pacman output: see above or:

[root@MilenaPC milena]# pacman -Sf lib32-glibc
resolving dependencies...
looking for inter-conflicts...

Targets (1): lib32-glibc-2.12-5

Total Download Size: 0.00 MB
Total Installed Size: 12.58 MB

Proceed with installation? [Y/n] y
checking package integrity...
error: extract: not overwriting dir with file opt/lib32/usr/include
(1/1) installing lib32-glibc [######################] 100%
error: problem occurred while installing lib32-glibc



Steps to reproduce:

pacman -Syu or pacman -S lib32-glibc
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Saturday, 28 August 2010, 08:56 GMT
Reason for closing:  None
Additional comments about closing:  Obsolete now that we have multilib.
Comment by Ionut Biru (wonder) - Friday, 30 July 2010, 06:07 GMT
it would be usefully if you did a pacman -Qo on those files from /opt/lib32/usr/include but now is useless since you did a -f
Comment by Ionut Biru (wonder) - Friday, 30 July 2010, 06:07 GMT
post the output of pacman -Qm
Comment by Lukas Jirkovsky (6xx) - Friday, 30 July 2010, 09:23 GMT
I think it has to be owned either by lib32-libtool or lib32-mpg123. See below.

I did pacman -Syu, the new package versions were:
lib32-glibc-2.12-5
lib32-libtool-2.2.10-2
lib32-mpg123-1.12.3-2

Now I got the conflict in lib32-glibc, so I run pacman -Su --ignore lib32-glibc. The lib32-libtool and lib32-mpg123 were upgraded. Then I did pacman -Su again and lib32-glibc installed without problems (no conflicting files).
Comment by ricsch (ricsch) - Friday, 30 July 2010, 12:27 GMT
In my case the following files are responsible for the conflict:

$ ls /opt/lib32/usr/include/
canberra-gtk.h canberra.h tdb.h

$ LANG=C pacman -Qo /opt/lib32/usr/include/tdb.h
/opt/lib32/usr/include/tdb.h is owned by lib32-tdb 3.4.3-4

$ LANG=C pacman -Qo /opt/lib32/usr/include/canberra.h
/opt/lib32/usr/include/canberra.h is owned by lib32-libcanberra 0.23-1

$ LANG=C pacman -Qo /opt/lib32/usr/include/canberra-gtk.h
/opt/lib32/usr/include/canberra-gtk.h is owned by lib32-libcanberra 0.23-1

Both packages come from AUR.
Comment by Ted Pavlic (tpavlic) - Wednesday, 04 August 2010, 12:45 GMT
Another example:

aur/lib32-linux-api-headers 2.6.34-1
(Kernel headers sanitized for use in userspace (32 Bit))

includes /opt/lib32/usr/include/scsi/scsi.h (and more)
Comment by Ted Pavlic (tpavlic) - Wednesday, 04 August 2010, 12:47 GMT
And regardless, i tseems like bad practice to symlink /opt/lib32/usr/include to the main /usr/include. For one, the long convention of using /opt/lib32/usr/include in Arch is the reason why so many AUR packages use it. Additionally, it is a good idea to separate out 32-bit parts from 64-bit parts.
Comment by Ionut Biru (wonder) - Wednesday, 04 August 2010, 12:49 GMT
@tpavlic stop giving us example with builds from aur. those have to be fixed and we don't care about AUR builds.
Comment by Lukas Jirkovsky (6xx) - Wednesday, 04 August 2010, 13:54 GMT
Just my two cents: I like having lib32-* includes in /opt much more than in system-wide /usr/include. I prefer to separate lib32 and bin32 things as much as possible. That's why I've 32bit chroot but for some applications (flash and wine) I prefer lib32.

Loading...