On Sat, Aug 13, 2016 at 02:42:34AM -0700, Chris Marusich wrote:
> Hi,
> 
> This patch adds sg3_utils (and libsgutils).
> 
> When I ran 'guix size sg3_utils', I noticed the following output, which
> seemed large to me.  Is it normal?
> 
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix size sg3_utils
> store item                                                       total    self
> /gnu/store/vbs91pmyw56m7sf8h7qvn465cbwbi24g-sg3_utils-1.42          74.9     2.4   3.2%
> /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib           60.9    22.9  30.5%
> /gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42             49.7     4.7   6.3%
> /gnu/store/68rzhy9px1njppv0nmbm8nk0sdkg5jx6-readline-6.3            45.0     1.2   1.6%
> /gnu/store/ld16jy012l3jpkj6azynzmldxn28cspw-ncurses-6.0             43.8     5.7   7.6%
> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23              38.1    36.7  49.0%
> /gnu/store/0010wvgs40kdq8chzsh403qm7la9jxq7-bash-static-4.3.42       1.4     1.4   1.9%
> total: 74.9 MiB
> --8<---------------cut here---------------end--------------->8---

The overall size looks normal to me. I don't understand how sg3_utils can be
2.4 MiB, while increasing the closure size by 14 MiB.

> It might be nice to package the library and the tools separately.  How
> might I do that?  The release tarball's README says the following, but I
> see no obvious way to split the build output into 3 separate packages:
> 
> "Various distributions (of Linux mainly) distribute sg3_utils as 3
> installable packages. One is a package containing the shared library
> discussed above (e.g. libsgutils2-2_1.33-0.1_i386.deb). A second package
> contains the utilities (e.g. sg3-utils_1.33-0.1_i386.deb) and depends on
> the first package). Finally there is an optional package that contains
> header files and a static library
> (e.g. libsgutils2-dev_1.33-0.1_i386.deb). This final package is only
> needed to build other packages (e.g. sdparm) that wish to use the
> sg3_utils shared library."

We tend not to create separate outputs unless there is a good reason. A
good reason could be a rarely used component that is disproportionately
large; we might try to put that in a separate output so it doesn't bloat
users' profiles unnecessarily.

A really good upstream build system will make this easy. Check the nmap
package definition for an example: we can build an install ndiff
directly into its own output, and this keeps the Python reference
separate from the default nmap output.