Subject: bug#29181: closed (Re: [bug#29181] [PATCH 1/1] gnu: mesa: Use symlinks instead of hard links.)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 08 Nov 2017 08:28:01 +0000

Your bug report

#29181: [PATCH core-updates 0/1] Shrink Mesa

which was filed against the guix-patches package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
29181: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29181
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [bug#29181] [PATCH 1/1] gnu: mesa: Use symlinks instead of hard links.
From: [email-masked] (Ludovic Courtès)
To: Marius Bakke <[email-masked]>
Cc: [email-masked]
Date: Wed, 08 Nov 2017 09:27:29 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Marius Bakke <[email-masked]> skribis:

> Ludovic Courtès <[email-masked]> writes:
>
>> This reduces the nar size (as shown by 'guix size') by 124 MiB, from
>> 169 MiB to 45 MiB (almost divided by 4!).
>
> Wow, nice catch.  If I read the code correctly, it detects hard links
> and replaces them with symlinks.

Yes.

> Could we do this unconditionally in a gnu-build-system phase?  Are
> there any legitimate uses of hard links in outputs?

Good question.  There might be situations where the software relies on
having regular files (not symlinks), so I would rather do it on a
case-by-case basis than have a standard phase.  WDYT?

Besides, a phase that looks at all the files would have to be efficient
than this naïve implementation.

> That said, the patch LGTM.

Pushed as dcc00f54c619118d11982383102d2e9a1b86d080, thanks!

Ludo’.

Subject: [PATCH core-updates 0/1] Shrink Mesa
From: Ludovic Courtès <[email-masked]>
To: [email-masked]
Cc: Ludovic Courtès <[email-masked]>
Date: Mon, 6 Nov 2017 22:40:57 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello Guix!

This patch divides the nar size of ‘mesa’ (as reported by ‘guix size’)
almost by a factor of four.  It does so by replacing hard links created
upon “make install” with symlinks.

The new post-install phase prints things like:

--8<---------------cut here---------------start------------->8---
starting phase `symlinks-instead-of-hard-links'
creating 7 symlinks to '/gnu/store/l1iwgjgp88snlzp9nafdpd0vvsqv7lsi-mesa-17.2.1/lib/dri/i915_dri.so'
creating 3 symlinks to '/gnu/store/l1iwgjgp88snlzp9nafdpd0vvsqv7lsi-mesa-17.2.1/lib/dri/i965_dri.so'
creating 1 symlinks to '/gnu/store/l1iwgjgp88snlzp9nafdpd0vvsqv7lsi-mesa-17.2.1/lib/dri/nouveau_drv_video.so'
creating 1 symlinks to '/gnu/store/l1iwgjgp88snlzp9nafdpd0vvsqv7lsi-mesa-17.2.1/lib/libXvMCnouveau.so.1.0.0'
creating 2 symlinks to '/gnu/store/l1iwgjgp88snlzp9nafdpd0vvsqv7lsi-mesa-17.2.1/lib/vdpau/libvdpau_nouveau.so.1.0.0'
phase `symlinks-instead-of-hard-links' succeeded after 0.0 seconds
--8<---------------cut here---------------end--------------->8---

The nar size does not reflect disk usage since deduplication would
recreate the hard links anyway, but it reflects how much we have to
transfer over the wire since the nar format does not represent hard
links.  A similar problem arose with Git a while back, see
<https://bugs.gnu.org/21949>.

I’d like to push to ‘core-updates’.

Thoughts?

Ludo’.

Ludovic Courtès (1):
  gnu: mesa: Use symlinks instead of hard links.

 gnu/packages/gl.scm | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

-- 
2.14.2