* Installing headers to a separate output?
@ 2016-02-25 20:32 Ricardo Wurmus
2016-02-25 20:40 ` Andreas Enge
2016-02-25 21:05 ` Efraim Flashner
0 siblings, 2 replies; 10+ messages in thread
From: Ricardo Wurmus @ 2016-02-25 20:32 UTC (permalink / raw
To: guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Installing headers to a separate output?
2016-02-25 20:32 Installing headers to a separate output? Ricardo Wurmus
@ 2016-02-25 20:40 ` Andreas Enge
2016-02-25 21:05 ` Efraim Flashner
1 sibling, 0 replies; 10+ messages in thread
From: Andreas Enge @ 2016-02-25 20:40 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Installing headers to a separate output?
2016-02-25 20:32 Installing headers to a separate output? Ricardo Wurmus
2016-02-25 20:40 ` Andreas Enge
@ 2016-02-25 21:05 ` Efraim Flashner
2016-02-26 23:24 ` Ludovic Courtès
1 sibling, 1 reply; 10+ messages in thread
From: Efraim Flashner @ 2016-02-25 21:05 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Installing headers to a separate output?
2016-02-25 21:05 ` Efraim Flashner
@ 2016-02-26 23:24 ` Ludovic Courtès
2016-02-27 11:33 ` Ricardo Wurmus
0 siblings, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2016-02-26 23:24 UTC (permalink / raw
To: Efraim Flashner; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Installing headers to a separate output?
2016-02-26 23:24 ` Ludovic Courtès
@ 2016-02-27 11:33 ` Ricardo Wurmus
2016-02-27 19:40 ` Pjotr Prins
0 siblings, 1 reply; 10+ messages in thread
From: Ricardo Wurmus @ 2016-02-27 11:33 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Installing headers to a separate output?
2016-02-27 11:33 ` Ricardo Wurmus
@ 2016-02-27 19:40 ` Pjotr Prins
2016-02-28 9:48 ` git download size Ricardo Wurmus
0 siblings, 1 reply; 10+ messages in thread
From: Pjotr Prins @ 2016-02-27 19:40 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: guix-devel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* git download size
2016-02-27 19:40 ` Pjotr Prins
@ 2016-02-28 9:48 ` Ricardo Wurmus
2016-02-28 15:17 ` Ludovic Courtès
2016-02-28 15:45 ` Ludovic Courtès
0 siblings, 2 replies; 10+ messages in thread
From: Ricardo Wurmus @ 2016-02-28 9:48 UTC (permalink / raw
To: Pjotr Prins; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git download size
2016-02-28 9:48 ` git download size Ricardo Wurmus
@ 2016-02-28 15:17 ` Ludovic Courtès
2016-02-28 15:46 ` Pjotr Prins
2016-02-28 15:45 ` Ludovic Courtès
1 sibling, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2016-02-28 15:17 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git download size
2016-02-28 9:48 ` git download size Ricardo Wurmus
2016-02-28 15:17 ` Ludovic Courtès
@ 2016-02-28 15:45 ` Ludovic Courtès
1 sibling, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2016-02-28 15:45 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git download size
2016-02-28 15:17 ` Ludovic Courtès
@ 2016-02-28 15:46 ` Pjotr Prins
0 siblings, 0 replies; 10+ messages in thread
From: Pjotr Prins @ 2016-02-28 15:46 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
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 :)
--
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-02-28 15:47 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-25 20:32 Installing headers to a separate output? Ricardo Wurmus
2016-02-25 20:40 ` Andreas Enge
2016-02-25 21:05 ` Efraim Flashner
2016-02-26 23:24 ` Ludovic Courtès
2016-02-27 11:33 ` Ricardo Wurmus
2016-02-27 19:40 ` Pjotr Prins
2016-02-28 9:48 ` git download size Ricardo Wurmus
2016-02-28 15:17 ` Ludovic Courtès
2016-02-28 15:46 ` Pjotr Prins
2016-02-28 15:45 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.