Skip to content

RFC Generating a graph of the size installed by each package

Yann E. MORIN buildroot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest4 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/4toolchain-external: split target installation from staging installation+0 -01 reply
1/4toolchain-external: split target installation from staging installation+0 -00 replies
2/4pkg-generic: add step_pkg_size global instrumentation hook+0 -01 reply
2/4pkg-generic: add step_pkg_size global instrumentation hook+0 -01 reply
2/4pkg-generic: add step_pkg_size global instrumentation hook+0 -00 replies
3/4support/scripts: add graph-size script+0 -00 replies
4/4Makefile: implement a graph-size target+0 -00 replies

Reviews trailers per patch

2 of 7 patches have a Reviewed-by or Acked-by.

PatchYann E. MORIN
1/4R-b T-b
1/4R-b T-b
2/4
2/4
2/4
3/4
4/4

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [Buildroot] [RFCv1 0/4] Generating a graph of the size installed by each package

Luca, All,

On 2014-06-24 15:05 +0200, Luca Ceresoli spake thusly:

Quoted 1 line

Thomas Petazzoni wrote:

[--SNIP--]

Quoted 14 lines
Quoted 10 lines

To see an example of the generated pie chart, see:

http://free-electrons.com/~thomas/pub/buildroot/graph-size.pdf

The implementation consists in adding a global instrumentation hook that registers which files are installed by each package. A limitation of the current implementation is that when a file is installed by a package A and then overriden by package B, the mechanism will assume the file was installed by package A. Suggestions to welcome on how to solve this in a reasonably simple way.

It's very well possible that I'm missing something, but I don't get why you need to save the list of all installed files.

Quoted 7 lines

Can't you just save the whole rootfs size before and after installation? It can be simply computer by 'du -bs $(TARGET_DIR)', and it's way easier to parse later. It would also take into account the change of size for overwritten files, for free.

Of course your approach collects more information, but I don't see these extra info used in the final graph.

What is important is not the installed size, but the actual size on the target.

The binaries installed are not stripped at instll time, but later, just before making the target images.

Thus, you want to wait for just before generationg the target image, but just after stripping binaries, to compute the actual size of each packages.

So, what the patches basically does is:
- record for each package what files are installed
- just after stripping, get the size of each file,
- assign the size to the package that installed that file

Of course, as Thomas says, if two packages install the same file, the first pacakge will be credited with the size of this file, not the last package.

Overcoming this would not be trivial (but not impossible either.) This can be refined in later interations of the patchset; we just need to come up with a simple-enough heuristic. Storing sha1s of each file before install, and comparign after install is a solution, but it is a bit more involved than just diffing the output of 'find -type f'.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'