From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: broken references in jar manifests Date: Thu, 1 Mar 2018 20:08:53 +0100 Message-ID: References: <87d10nmxrw.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1144a15843b56705665e97d2" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erTZY-00058N-Nd for guix-devel@gnu.org; Thu, 01 Mar 2018 14:08:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erTZX-0005GF-9R for guix-devel@gnu.org; Thu, 01 Mar 2018 14:08:56 -0500 Received: from mail-io0-x232.google.com ([2607:f8b0:4001:c06::232]:36933) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erTZX-0005Fz-1B for guix-devel@gnu.org; Thu, 01 Mar 2018 14:08:55 -0500 Received: by mail-io0-x232.google.com with SMTP id d71so8254891iog.4 for ; Thu, 01 Mar 2018 11:08:54 -0800 (PST) In-Reply-To: <87d10nmxrw.fsf@elephly.net> 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" To: Ricardo Wurmus Cc: Guix-devel , Ricardo Wurmus --001a1144a15843b56705665e97d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-03-01 19:54 GMT+01:00 Ricardo Wurmus : > > G=C3=A1bor Boskovits writes: > > > 2018-03-01 18:11 GMT+01:00 Ricardo Wurmus > : > > > >> Hi Guix, > >> > >> we have a problem with jar manifests. When we use the Class-Path > >> property to ensure that an executable can find its dependencies on the > >> class path at run-time, we end up with a manifest like this: > >> > >> --8<---------------cut here---------------start------------->8--- > >> Manifest-Version: 1.0 > >> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-java-htsjdk-2. > >> 10.1/share/java/htsjdk.jar > >> Created-By: 1.8.0_151 (Oracle Corporation) > >> Main-Class: picard.cmdline.PicardCommandLine > >> --8<---------------cut here---------------end--------------->8--- > >> > >> Note that the Class-Path property is broken into two lines. This mean= s > >> that the reference scanner will miss it and grafting will fail. > >> > >> > > Could we modify the reference scanner to find these lines? > > Would there be any serious drawback to that? > > The reference scanner needs to be fast. The scheme version is heavily > optimized to do quickly replace references for the purpose of grafting. > The C++ version will eventually be replaced with the Scheme version as > the daemon gets replaced. > > An alternative to recording full references in the manifest file is to > install a =E2=80=9Clib=E2=80=9D directory that contains symlinks to depen= dencies. The > manifest can then contain relative paths to these symlinks. > > I guess I would prefer to do this instead. > That=E2=80=99s what I did in the package definition for dropseq-tools. > > Unfortunately I cannot find this package. Where should I look for it? > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > --001a1144a15843b56705665e97d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -03-01 19:54 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=

G=C3=A1bor Boskovits <boskovits@g= mail.com> writes:

> 2018-03-01 18:11 GMT+01:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:
>
>> Hi Guix,
>>
>> we have a problem with jar manifests.=C2=A0 When we use the Class-= Path
>> property to ensure that an executable can find its dependencies on= the
>> class path at run-time, we end up with a manifest like this:
>>
>> --8<---------------cut here---------------start-----------= -->8---
>> Manifest-Version: 1.0
>> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-= java-htsjdk-2.
>>=C2=A0 10.1/share/java/htsjdk.jar
>> Created-By: 1.8.0_151 (Oracle Corporation)
>> Main-Class: picard.cmdline.PicardCommandLine
>> --8<---------------cut here---------------end-------------= -->8---
>>
>> Note that the Class-Path property is broken into two lines.=C2=A0 = This means
>> that the reference scanner will miss it and grafting will fail. >>
>>
> Could we modify the reference scanner to find these lines?
> Would there be any serious drawback to that?

The reference scanner needs to be fast.=C2=A0 The scheme version is = heavily
optimized to do quickly replace references for the purpose of grafting.
The C++ version will eventually be replaced with the Scheme version as
the daemon gets replaced.

An alternative to recording full references in the manifest file is to
install a =E2=80=9Clib=E2=80=9D directory that contains symlinks to depende= ncies.=C2=A0 The
manifest can then contain relative paths to these symlinks.


I guess I would prefer to do this inst= ead.
=C2=A0
That=E2=80=99s what I did in the package definition for dropseq-tools.


Unfortunately I cannot find this packa= ge. Where should I look for it?
=C2=A0
--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net



--001a1144a15843b56705665e97d2--