Bug 11046

Summary: Git package binaries are ~180MB (compared to ~20MB in stable branches).
Product: buildroot Reporter: Paul Stewart <paul>
Component: OtherAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: buildroot
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Host: Target:
Build:
Attachments: Test config from Y Morin.

Description Paul Stewart 2018-05-24 18:16:46 UTC
Created attachment 7601 [details]
Test config from Y Morin.

When I build a config with git enabled with 2018.05-rc2 the git binaries in /usr/libexec/git-core are over 180MB.  When I build the same config with 2018.02.2 (and all other stable versions I have used over the last few years) the binaries are ~20MB or less.

Steps to reproduce:
1. Check out 2018.02.2 from git repo
2. Build the attached config.
3. Examine the git-core folder in the image tar file.
4. Check out 2018.05-rc2 from git repo
5. Build the attached config.
6. Examine the git-core folder in the image tar file.

My build system is openSUSE Leap 42.3 fully patched.
Comment 1 Arnout Vandecappelle 2018-05-27 14:40:51 UTC
I was not able to reproduce the issue with the given config. The executables are all hardlinked with eachother in both versions.

Are you sure you don't have some post-image script that clones the hardlinks?

I suspected patchelf as a potential culprit, but it does open(fileName, O_TRUNC | O_WRONLY) which should preserve hardlinks (as proven by bug 11031).

Can you check if the copies are made during the install of git itself, or during the target-finalize step, or maybe even during rootfs generation?
Comment 2 Paul Stewart 2018-05-27 17:37:30 UTC
(In reply to Arnout Vandecappelle from comment #1)

The post scripts only run if they are called out in the config, right?  Either way, none of my scripts do anything with git.  I can definitely reproduce with the attached, minimal, config.

The binaries are normal in target/usr/libexec/git-core. So I think you're on the right track.

What's the best way for me to determine: "if the copies are made during the install of git itself, or during the target-finalize step, or maybe even during rootfs generation"?
Comment 3 Peter Korsgaard 2018-05-27 20:25:50 UTC
(In reply to Paul Stewart from comment #2)
# The binaries are normal in target/usr/libexec/git-core. So I think you're on the right track.

Ahh, now we are talking. This I can reproduce:

du -hs target images/rootfs.tar
17M     target
191M    images/rootfs.tar

I will take a closer look and see where this comes from.
Comment 4 Peter Korsgaard 2018-05-27 20:51:10 UTC
This was indeed caused by a recent change to make a copy of output/target before running the file system hooks and generate file systems, and this copy used rsync without the -H (preserve hard links) option.

I have sent a patch to fix it:
http://patchwork.ozlabs.org/patch/921203/