From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: [PATCH 3/3] gnu: Add ruby-i18n. Date: Wed, 1 Oct 2014 15:49:08 -0400 Message-ID: References: <1411917760-28557-1-git-send-email-dthompson2@worcester.edu> <1411917760-28557-3-git-send-email-dthompson2@worcester.edu> <877g0j4miz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZPtn-0007ov-O8 for guix-devel@gnu.org; Wed, 01 Oct 2014 15:49:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZPtg-00008A-Ji for guix-devel@gnu.org; Wed, 01 Oct 2014 15:49:19 -0400 Received: from na6sys009bog033.obsmtp.com ([74.125.150.107]:57063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZPtg-000080-EQ for guix-devel@gnu.org; Wed, 01 Oct 2014 15:49:12 -0400 Received: by mail-la0-f46.google.com with SMTP id gi9so1102265lab.5 for ; Wed, 01 Oct 2014 12:49:09 -0700 (PDT) In-Reply-To: <877g0j4miz.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel On Wed, Oct 1, 2014 at 3:28 PM, Ludovic Court=C3=A8s wrote: > Hello, > > I just noticed this: > > $ guix gc --references /gnu/store/whj6j9f34adpzwhfj3qf00fcq9zsb3hp-ruby= -i18n-0.6.11 > [nothing here] > > Apparently the .gem is +/- a gzip archive, which makes it opaque to the > GC, hence the above result. > > Is it something we should worry about, or is it fine because .gem files > in general don=E2=80=99t won=E2=80=99t hold any reference to something el= se? > There should be many other files there, too, right? The Ruby source should be there in plain text. In the case of the i18n gem, it doesn't depend on any external librararies, so there's no references to be found since it doesn't directly refer to the Ruby interpreter that built the gem (should it?). Now, when a gem has other dependencies, my suspicion is that there also won't be any references, which is definitely something to worry about. I guess the Ruby build system needs to be adjusted to do something similar to the shebang substitution, but for gem paths. That might be really tough to do reliably, though. Sorry that I don't have a better answer right now. I guess I should take a look at how Nix handles this. Thanks for letting me know. - Dave