Re: broken references in jar manifests

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

2018-03-01 19:54 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Gábor Boskovits <boskovits@gmail.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.  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 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.  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 “lib” directory that contains symlinks to dependencies.  The
> manifest can then contain relative paths to these symlinks.
>
>
I guess I would prefer to do this instead.


> That’s 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 2933 bytes --]