Installing headers to a separate output?

Installing headers to a separate output?

[Ricardo Wurmus]

Hi Guix,

should we install headers to separate outputs as we do it in some cases
for really large documentation?  It seems wrong to me to download
substitutes for libraries when at build time only certain headers are
needed.

Other distributions have separate “*-devel” or “*-dev” packages (and I’m
ambivalent about this) — would it be a bad idea if we provided “devel”
or “dev” *outputs* so that users had more control over what ends up in
their store?

I’m not writing this because I’m annoyed by the current behaviour — I’m
just curious.

~~ Ricardo

Re: Installing headers to a separate output?

[Andreas Enge]

On Thu, Feb 25, 2016 at 09:32:22PM +0100, Ricardo Wurmus wrote:
> Other distributions have separate “*-devel” or “*-dev” packages (and I’m
> ambivalent about this) — would it be a bad idea if we provided “devel”
> or “dev” *outputs* so that users had more control over what ends up in
> their store?

Personally I find this really annoying and am happy that we just install
a package (most of the time) as the result of "make install". Otherwise,
we would also almost systematically need to add the header outputs as
build inputs.

Andreas

Re: Installing headers to a separate output?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Thu, 25 Feb 2016 21:32:22 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> Hi Guix,
> 
> should we install headers to separate outputs as we do it in some cases
> for really large documentation?  It seems wrong to me to download
> substitutes for libraries when at build time only certain headers are
> needed.
> 
> Other distributions have separate “*-devel” or “*-dev” packages (and I’m
> ambivalent about this) — would it be a bad idea if we provided “devel”
> or “dev” *outputs* so that users had more control over what ends up in
> their store?
> 
> I’m not writing this because I’m annoyed by the current behaviour — I’m
> just curious.
> 
> ~~ Ricardo

I thought a bit about it before and I don't really think it'll save that much
space. Most of the time the headers are a small part of the total package,
and the fine-tuning that comes with chosing exactly which outputs from a
build process you actually want seem like they should be left as
encouragement for people to hack their systems.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Installing headers to a separate output?

[Ludovic Courtès]

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Thu, 25 Feb 2016 21:32:22 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> Hi Guix,
>> 
>> should we install headers to separate outputs as we do it in some cases
>> for really large documentation?  It seems wrong to me to download
>> substitutes for libraries when at build time only certain headers are
>> needed.
>> 
>> Other distributions have separate “*-devel” or “*-dev” packages (and I’m
>> ambivalent about this) — would it be a bad idea if we provided “devel”
>> or “dev” *outputs* so that users had more control over what ends up in
>> their store?
>> 
>> I’m not writing this because I’m annoyed by the current behaviour — I’m
>> just curious.
>> 
>> ~~ Ricardo
>
> I thought a bit about it before and I don't really think it'll save that much
> space. Most of the time the headers are a small part of the total package,
> and the fine-tuning that comes with chosing exactly which outputs from a
> build process you actually want seem like they should be left as
> encouragement for people to hack their systems.

Seconded.  We can add a separate “include” output (there’s already a
special case for that in gnu-build-system) on a case-by-case basis, like
we do for documentation, but in practice, I’ve never seen a case where
moving headers away would be a significant space saving.

IOW, it’d be a micro-optimization; there are other things we could do
before that to save space.

Ludo’.

Re: Installing headers to a separate output?

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Efraim Flashner <efraim@flashner.co.il> skribis:
>
>> On Thu, 25 Feb 2016 21:32:22 +0100
>> Ricardo Wurmus <rekado@elephly.net> wrote:
>>
>>> Hi Guix,
>>> 
>>> should we install headers to separate outputs as we do it in some cases
>>> for really large documentation?  It seems wrong to me to download
>>> substitutes for libraries when at build time only certain headers are
>>> needed.
>>> 
>>> Other distributions have separate “*-devel” or “*-dev” packages (and I’m
>>> ambivalent about this) — would it be a bad idea if we provided “devel”
>>> or “dev” *outputs* so that users had more control over what ends up in
>>> their store?
>>> 
>>> I’m not writing this because I’m annoyed by the current behaviour — I’m
>>> just curious.
>>> 
>>> ~~ Ricardo
>>
>> I thought a bit about it before and I don't really think it'll save that much
>> space. Most of the time the headers are a small part of the total package,
>> and the fine-tuning that comes with chosing exactly which outputs from a
>> build process you actually want seem like they should be left as
>> encouragement for people to hack their systems.
>
> Seconded.  We can add a separate “include” output (there’s already a
> special case for that in gnu-build-system) on a case-by-case basis, like
> we do for documentation, but in practice, I’ve never seen a case where
> moving headers away would be a significant space saving.

Thank you all for your comments.  I agree that it makes sense to do this
on a case-by-case basis only.

Curiosity: satisfied :)

~~ Ricardo

Re: Installing headers to a separate output?

[Pjotr Prins]

On Sat, Feb 27, 2016 at 12:33:11PM +0100, Ricardo Wurmus wrote:
> >> I thought a bit about it before and I don't really think it'll save that much
> >> space. Most of the time the headers are a small part of the total package,
> >> and the fine-tuning that comes with chosing exactly which outputs from a
> >> build process you actually want seem like they should be left as
> >> encouragement for people to hack their systems.
> >
> > Seconded.  We can add a separate “include” output (there’s already a
> > special case for that in gnu-build-system) on a case-by-case basis, like
> > we do for documentation, but in practice, I’ve never seen a case where
> > moving headers away would be a significant space saving.
> 
> Thank you all for your comments.  I agree that it makes sense to do this
> on a case-by-case basis only.
> 
> Curiosity: satisfied :)

Can we make the git binary download smaller? I think it is one of the
largest ones now in Guix. Since git is a small tool it really
shouldn't be that large despite that Linus was involved and some
people say it may be a larger contribution for posterity than the
kernel ;)

Pj.

git download size

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> Can we make the git binary download smaller? I think it is one of the
> largest ones now in Guix. Since git is a small tool it really
> shouldn't be that large despite that Linus was involved and some
> people say it may be a larger contribution for posterity than the
> kernel ;)

I just build git and this is what I see:

    rekado in guix: du -sh /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
    23M	/gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3

However:

    Found valid signature for /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
    From http://hydra.gnu.org/nar/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
    Downloading jijqv5...-git-2.6.3 (247.2MiB installed)...
     http://hydra.gnu.org/nar/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3 792KiB/s 02:19 | 107.9MiB transferred

Why the difference?

Here’s the output of “guix size /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3”:

store item                                                       total    self
/gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3              761.1   247.2  32.5%
/gnu/store/bl07pj3dx8a6iaaklyclcpav35wy3wzz-curl-7.47.0            433.0     1.8   0.2%
/gnu/store/4bs4mx6xyx0jx9827vmmbxyhjln7cmcv-python-2.7.10          408.2    77.2  10.1%
/gnu/store/8jbgzwlc561wws115fh5vvpbnn0d60yg-openldap-2.4.42        383.9     7.2   1.0%
/gnu/store/d3xdc2w87yw3raafwb9q34gxx4xqci8k-cyrus-sasl-2.1.26      325.1     0.8   0.1%
/gnu/store/qvx4q6lbwi4s3cwr8wqaa7kcva0a5c4b-openssl-1.0.2f         319.9    12.3   1.6%
/gnu/store/x2p2biyybcb2wac77qz9468asc5fm48i-perl-5.22.1            307.6    49.8   6.5%
/gnu/store/pg8nnqprjxgwhwiyh8nhbphzj53ax77i-gcc-4.9.3              138.2    77.1  10.1%
/gnu/store/d9f7dfg6q6qq09a704wqgqziqh4a01va-icu4c-55.1             124.4    34.9   4.6%
/gnu/store/9y1sb141yyv9x8bc6z03hdiq4v6h5xj8-gss-1.0.3              117.4     0.5   0.1%
/gnu/store/igy897yp0cd13133skf66zbwga1z4q6x-shishi-1.0.2           116.9     2.6   0.3%
/gnu/store/wcz0m4cxy0s9siwdf1630wkp35k2ww2r-gnutls-3.4.7           113.0     4.0   0.5%
/gnu/store/43a6v9hslld0nx627nyr365zih1p41h5-make-4.1               106.9     1.2   0.2%
/gnu/store/l5d5pw7a3mg8smx120fgrjakd109qzbq-guile-2.0.11           105.7    16.1   2.1%
/gnu/store/gscrqqf4yf9pchb58gg6h362arkhsw2q-guile-2.0.11           105.7    16.1   2.1%
/gnu/store/gbg76f0x503bkjr1pcv1n37plph2b7ha-binutils-2.25.1         82.5    44.6   5.9%
/gnu/store/nl4g5nzfdy6fad6i1zgxp1gin5c73b47-coreutils-8.24          77.8    13.8   1.8%
/gnu/store/0fwiw8rnf9gm8binrmnlw739ri9m8lxv-bdb-5.3.21              77.3    16.6   2.2%
/gnu/store/lb790wi1xjac30ffjmbvmgx4q2376a2b-mit-krb5-1.13.3         76.2     3.9   0.5%
/gnu/store/xqvwn89wb5ja81pxsy3m7lqlwq8mf3zw-gawk-4.1.3              75.2     2.9   0.4%
/gnu/store/3fhgi8jljfagg4yzmcn4abxs78abm7yc-libssh2-1.4.3           75.1     0.6   0.1%
/gnu/store/4iqlcz069gw3qnx2iry9yifwg9mc5k51-libgcrypt-1.6.5         74.1     1.1   0.1%
/gnu/store/y6y7flmdr4r1z2gha7algngw1m29q6df-libgcrypt-1.5.4         73.7     0.8   0.1%
/gnu/store/5srj5qj6qhbwvrnlmnj8bihj6qbwb4v3-xz-5.2.2                73.4     1.1   0.1%
/gnu/store/zpxg45dq67psrn4wmfk4l635h0si8q63-libgpg-error-1.21       73.0     0.6   0.1%
/gnu/store/8qqi9pjcpb8lph39g9ppyqzaq38hdvdg-bzip2-1.0.6             72.9     0.5   0.1%
/gnu/store/jbzyly3wcwbkhd9ai97d2a129i8rhpbk-readline-6.3            67.7     1.2   0.2%
/gnu/store/vl728iydxaiwbacfj245k3x6qyl7d1ga-readline-6.3            67.6     1.2   0.2%
/gnu/store/6fpfcqpm85k777rsdrb3d2pd91p2h4ll-ncurses-6.0             66.4     5.7   0.7%
/gnu/store/b02lmk67jq1vcflk2m2bwzc8gmwmndqp-ncurses-6.0             66.4     5.7   0.7%
/gnu/store/09gwygs9vdja1bkpyfqsb51rjzs7d5zs-libunistring-0.9.6      65.2     4.5   0.6%
/gnu/store/h85a5abj5z9kxsjqb1zf0zixdf65qz8l-libunistring-0.9.6      65.2     4.5   0.6%
/gnu/store/ysywlajf3mssmb3rpa4819fmr54jd56a-nettle-3.2              65.0     1.7   0.2%
/gnu/store/8v3jina1v71fi4n1gcs729jvrc777giy-file-5.25               64.6     3.9   0.5%
/gnu/store/1xlfngcpc74cvlr5bnzjv25nwsiyn0gp-sqlite-3.10.0           63.9     3.2   0.4%
/gnu/store/1hc749rww6b4dzmmilz5qfri11k6087g-gmp-6.1.0               63.3     2.6   0.3%
/gnu/store/zx7fwds22418n3vjyh8qk55l2jh06ry0-gmp-6.1.0               63.3     2.6   0.3%
/gnu/store/8gzp3sj5lainqr90qzg908gzgbq5ganq-gmp-6.1.0               63.3     2.6   0.3%
/gnu/store/qjzi4vvbqrpbjfdg8hvkv43qlkhcx0v7-libgc-7.4.2             62.5     1.1   0.2%
/gnu/store/8cv92vy3m47v2b2pf73jdz9k26lzl1xw-libgc-7.4.2             62.5     1.1   0.2%
/gnu/store/36n9cb1rj8hnz5f43rh04kyqmipg8h9q-pkg-config-0.29         62.0     1.3   0.2%
/gnu/store/nqh64v4dnm0bv9r1c1r9rdvl72licxp3-pkg-config-0.29         62.0     1.3   0.2%
/gnu/store/mkbdzvwwvzq6dzchz17j1vhisdvxklii-libidn-1.32             61.5     0.8   0.1%
/gnu/store/2m3yvag3bvsy812dqbvxmxlra2hcpwd4-acl-2.2.52              61.4     0.4   0.1%
/gnu/store/xf5x5hki5dhvsx63k2rizzsivik3s5rw-expat-2.1.0             61.3     0.6   0.1%
/gnu/store/9lm6j1fvbj67bk2rsm17gilh9fpxjiq8-gdbm-1.11               61.2     0.5   0.1%
/gnu/store/m7ac4hqvbyzf0fwjp5q85v6l8183r6h5-libcap-2.24             61.1     0.1   0.0%
/gnu/store/8spals8f7ggd8df1i4a5yir1v0vsb5pj-zlib-1.2.8              61.1     0.4   0.0%
/gnu/store/npifhd78kiam0az50clnpalgr0ycmyqy-libtasn1-4.7            61.1     0.3   0.0%
/gnu/store/83hq072klq4bj46l297ihwyp7wg3jy41-attr-2.4.47             61.0     0.2   0.0%
/gnu/store/cx4dknnwm6dfha504hriss6nspilccz1-libffi-3.2.1            60.8     0.1   0.0%
/gnu/store/vk83x59c8ah5pjc5axrbmd58f88cz4wf-libffi-3.2.1            60.8     0.1   0.0%
/gnu/store/64fk1rj1ykjd9miplzvgnz5bfyhwspw0-libltdl-2.4.6           60.8     0.1   0.0%
/gnu/store/vac75z1zl9lxbr5g663ygn2i9wlvb543-libltdl-2.4.6           60.8     0.1   0.0%
/gnu/store/pkasxagsa4z4viscfpl6sjszmdmwncl1-gcc-4.9.3-lib           60.7    22.9   3.0%
/gnu/store/x8dmdlrn5qn0wrbcnngj55y3ab73h0pp-bash-4.3.42             49.5     4.7   0.6%
/gnu/store/0bxy0vmwf7l3nsz5yr71hmvay5aw9pw3-readline-6.3            44.8     1.2   0.2%
/gnu/store/bh25hb3hqr6dvxxhfm4hd9hjsxsf1f95-ncurses-6.0             43.6     5.7   0.7%
/gnu/store/sgzfawy95pfn7nsw3xvmca58llm5zzbc-glibc-2.22              37.9    36.5   4.8%
/gnu/store/1481x54il6kf3kcs03g997yaj86mfvkh-linux-libre-headers-3.14.37     3.3     3.3   0.4%
/gnu/store/h534pmpvqr5svh0vp238ndph4gv9g51i-bash-static-4.3.42       1.4     1.4   0.2%
/gnu/store/7sbnxbfwzxn4fwkpa10x07gb5hr5hh62-libatomic-ops-7.4.2      0.6     0.6   0.1%
/gnu/store/ilar1qmj2jvjiygwmfcwhny5c7vzsaks-libatomic-ops-7.4.2      0.6     0.6   0.1%
/gnu/store/y1agigxaf3idy2rsb9j9sb6r5apqf3x8-curl-7.47.0-doc          0.5     0.5   0.1%
/gnu/store/dyz3dsbxa3h4dzwaxv4ibjdl5hbj9w2f-zlib-1.2.8               0.4     0.4   0.0%

~~ Ricardo

Re: git download size

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> Can we make the git binary download smaller? I think it is one of the
>> largest ones now in Guix. Since git is a small tool it really
>> shouldn't be that large despite that Linus was involved and some
>> people say it may be a larger contribution for posterity than the
>> kernel ;)
>
> I just build git and this is what I see:
>
>     rekado in guix: du -sh /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
>     23M	/gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
>
> However:
>
>     Found valid signature for /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
>     From http://hydra.gnu.org/nar/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
>     Downloading jijqv5...-git-2.6.3 (247.2MiB installed)...
>      http://hydra.gnu.org/nar/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3 792KiB/s 02:19 | 107.9MiB transferred
>
> Why the difference?

See <http://bugs.gnu.org/21949>.

Ludo’.

Re: git download size

[Pjotr Prins]

On Sun, Feb 28, 2016 at 04:17:58PM +0100, Ludovic Courtès wrote:
> > Why the difference?
> 
> See <http://bugs.gnu.org/21949>.

Just great :)

-- 

Re: git download size

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> Can we make the git binary download smaller? I think it is one of the
>> largest ones now in Guix. Since git is a small tool it really
>> shouldn't be that large despite that Linus was involved and some
>> people say it may be a larger contribution for posterity than the
>> kernel ;)
>
> I just build git and this is what I see:
>
>     rekado in guix: du -sh /gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3
>     23M	/gnu/store/jijqv58gszv4wa4j92l3aj0f9znrj7ly-git-2.6.3

The fix turned out to be simple enough: commit 1a59b6d should solve the
problem!

Ludo’.