Bug 11046 - Git package binaries are ~180MB (compared to ~20MB in stable branches).
Summary: Git package binaries are ~180MB (compared to ~20MB in stable branches).
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-24 18:16 UTC by Paul Stewart
Modified: 2018-05-27 21:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
Test config from Y Morin. (144 bytes, application/octet-stream)
2018-05-24 18:16 UTC, Paul Stewart 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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/