all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.