Re: broken references in jar manifests

[Ricardo Wurmus <rekado@elephly.net>]

Chris Marusich <cmmarusich@gmail.com> writes:

>>> >> 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.
>
> That is quite unfortunate.  :-(
>
>>> 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.
>
> Sounds good to me, too.

Actually, I think this wouldn’t work after all.  When the references in
the Class-Path property are split up they would be overlooked when
grafting.  The references in the separate custom file would be grafted.
The result is that the applications would keep trying to load the old,
ungrafted jars while Guix would think that the package only retained
references to the grafted packages.

Equally bad: the garbage collector would trash these ungrafted
references as it cannot detect them, thus breaking the application.

--
Ricardo

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