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#42735 - [gcc-multilib] bin files are duplicates instead of symlinks

Attached to Project: Community Packages
Opened by Christian Krause (wookietreiber) - Monday, 10 November 2014, 20:15 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 15 November 2014, 04:46 GMT
Task Type General Gripe
Category Packages: Multilib
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description
-----------

- there are some files in the package which are duplicate (see checksum below), which aren't symlinks
- storage space could be saved if they were symlinks, e.g. ln -sf in package function in PKGBUILD
- I don't know if this is an Arch Linux packaging issue or rather one to solve by upstream devs
- may be true as well for the std (non-multilib) gcc packages for i686 and x86_64


Additional info
---------------

- package version(s): gcc-multilib 4.9.2-1


Steps to reproduce
------------------

- I did just a count on the md5s here:

$ pacman -Qql gcc-multilib | grep -E '^/usr/bin/.+' | xargs md5sum | awk '{ print $1 }' | sort | uniq -c | sed 's/^/ /'
1 3d333df77302ed89e06a4a8539943b7d
1 778da7247a9562ab8fba9d49bc1b35ae
1 8597e474811eabd635890601aa9fda57
2 a7db979089a43a8dda99725d9ae1e7d9
4 aef4e4b3a379be58e1d69bdc5912edb1
4 afd16e37ba09188aa94b848493dec011
2 c3c83b7421a40696bbfff7c59d13aafc
2 c55f49cd4010a9388f30fd4b3f81f523
1 da96f545b863e57c6ab2598c1ea9a740

- only one file of those is a symlink:

$ pacman -Qql gcc-multilib | grep -E '^/usr/bin/.+' | xargs file | grep 'symbolic link'
/usr/bin/cc: symbolic link to `gcc'
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 15 November 2014, 04:46 GMT
Reason for closing:  Not a bug
Comment by Christian Krause (wookietreiber) - Monday, 10 November 2014, 20:16 GMT
Oh, the syntax ... I wrote markdown ...
Comment by Allan McRae (Allan) - Tuesday, 11 November 2014, 00:32 GMT
Are they hardlinks?
Comment by Christian Krause (wookietreiber) - Tuesday, 11 November 2014, 08:21 GMT
How can I tell?

As it seems, at least from this post, I can't:

http://unix.stackexchange.com/a/122341/64468
Comment by Allan McRae (Allan) - Tuesday, 11 November 2014, 08:26 GMT
ls -i.
Comment by Christian Krause (wookietreiber) - Friday, 14 November 2014, 17:03 GMT
Yes, there are definitely multiple inodes:

$ pacman -Qql gcc-multilib | grep -E '^/usr/bin/.+' | parallel ls -i
3437202 /usr/bin/c++
3437208 /usr/bin/c89
3437209 /usr/bin/c99
3437207 /usr/bin/cc
3437210 /usr/bin/cpp
3437202 /usr/bin/g++
3437203 /usr/bin/gcc
3437204 /usr/bin/gcc-ar
3437205 /usr/bin/gcc-nm
3437206 /usr/bin/gcc-ranlib
3437211 /usr/bin/gcov
3437202 /usr/bin/x86_64-unknown-linux-gnu-c++
3437202 /usr/bin/x86_64-unknown-linux-gnu-g++
3437203 /usr/bin/x86_64-unknown-linux-gnu-gcc
3437203 /usr/bin/x86_64-unknown-linux-gnu-gcc-4.9.2
3437204 /usr/bin/x86_64-unknown-linux-gnu-gcc-ar
3437205 /usr/bin/x86_64-unknown-linux-gnu-gcc-nm
3437206 /usr/bin/x86_64-unknown-linux-gnu-gcc-ranlib
Comment by Christian Krause (wookietreiber) - Friday, 14 November 2014, 17:13 GMT
Some follow-ups questions:

- Does this effect the size of the packages tarball? (I guess not, but want to be sure.)
- Is there a reason why they are using hardlinks over symlinks? (I'd like to understand.)

If all is well with the reasoning and so on, I guess the issue can be closed.

I apologize, if I wasted anyones time -- I really didn't think about hard links. Most likely, because I don't use them (really can't remember if I ever used them, that's why there's follow up questions).
Comment by Doug Newgard (Scimmia) - Saturday, 15 November 2014, 04:44 GMT
In simple terms, what you see as a file is actually just a reference to some data on the disk. A "hardlink" is just another reference to that same data; it's essentially the same file. A "symlink" is more of a reference to the reference, which won't always function the same.

Loading...