Re: “generate-jar-indices” phase fails on many packages

Re: “generate-jar-indices” phase fails on many packages

[Danny Milosavljevic]

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

Hi Ricardo,

did you get a bug# for this?  I can't see it on https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix ...

> The errors are either about duplicates as in java-picard-2.10.3:
> 
>     duplicate entry: htsjdk/samtools/AbstractBAMFileIndex$1.class

That's... bad.  What if those files differed?  Which one would be used at
runtime?

> or about missing files as in dropseq-tools:
> 
>     java.io.FileNotFoundException: /gnu/store/q76y0ximcziplgfpbn26kbw4h3s14f33-dropseq-tools-1.13/share/java/lib/biojava-alignment.jar

That's also bad.  How does it run at all if its dependencies are missing?

> I have removed the phase in these packages, but that’s not ideal.

I think that's suboptimal in the above cases since those error messages report
real problems, or in the first case at least pointing to a potential problem.

> Can we make this phase more robust?

Right now, it just invokes

  jar -i

with the finished jar file.  That's as simple as it gets - and I specifically
did only that minimal implementation for this cycle in order to only fix our GC
problem with java packages.

The only thing I can think of that would improve things long term:

The phase can add relative paths to all the dependencies to META-INF/MANIFEST.MF
before invoking "jar -i".
Then "jar -i" will index those - and all java packages can use regular inputs
instead of propagated inputs.  I've tested that locally already - and it
works fine.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]