GNU bug report logs - #29896
[PATCH core-updates] gnu: java-asm: Update to 6.0.

Previous Next

Full log

Message #32 received at 29896 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 29896 <at> debbugs.gnu.org
Subject: Re: [bug#29896] [PATCH] gnu: java-asm: Update to 6.0.
Date: Sat, 20 Jan 2018 12:24:24 +0100

Le Sat, 20 Jan 2018 10:08:04 +0100,
Gábor Boskovits <boskovits <at> gmail.com> a écrit :

> 2018-01-20 8:50 GMT+01:00 Chris Marusich <cmmarusich <at> gmail.com>:
> 
> > Leo Famulari <leo <at> famulari.name> writes:
> >  
> > > On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:  
> > >> Even though we added some inputs, there appear to be no retained
> > >> references in the output, as shown by this command:
> > >>
> > >>   guix gc --referrers $(./pre-inst-env guix build java-asm)  
> > >
> > > To check the retained references in the output [0], it's actually
> > > `guix gc --references $(./pre-inst-env guix build ...)`.
> > >
> > > [0] To clarify "retained references", they are literally
> > > occurences of strings that begin with '/gnu/store/', then a Guix
> > > hash, then a hyphen, and then a package name.  
> >
> > You're right; this was a "thinko" on my part.  I meant to write
> > "--references" instead of "--referrers".  The output of the correct
> > command is still empty, so there are still no references.
> >
> > Ricardo Wurmus <rekado <at> elephly.net> writes:
> >  
> > > Chris Marusich <cmmarusich <at> gmail.com> writes:
> > >  
> > >> If the new input is also required at runtime, then I'm not sure
> > >> this package definition is correct.  I would normally expect a
> > >> "runtime dependency" to be either retained as a reference in the
> > >> output, or declared as a propagated-input (so that it gets
> > >> installed alongside this package when this package is installed
> > >> into a profile).  Perhaps I am missing some information here.
> > >>
> > >> I'm hoping Ricardo can comment on how this is intended to work
> > >> for Java packages, since he originally added the
> > >> ant-build-system.  
> > >
> > > The jars that the ant-build-system generates are uncompressed and
> > > thus allow the scanner to find embedded store references.  The
> > > problem seems to be that references to other *jars* are not kept,
> > > because they are never recorded anywhere.  That’s normal for
> > > Java, which looks for named classes on the classpath, i.e. a list
> > > of jars.  It behaves very much like Python and its PYTHONPATH in
> > > this regard.
> > >
> > > The best we can do here is to propagate inputs.  The alternative
> > > is to try to be smart and record the effective runtime classpath,
> > > but that’s hard/impossible to get right.  
> >
> > OK - thank you for the explanation!  In light of that information, I
> > think that in the case of a package that uses the ant-build-system
> > (like java-asm), if we know for sure that an input is required at
> > runtime, we should make it a propagated input.  The installed
> > software still won't work without additional work on the part of
> > the user (e.g., the user needs to set the CLASSPATH when invoking
> > java, or use java's -cp option), but for now at least making the
> > input a propagated input will ensure that it gets installed
> > alongside the package which at runtime requires it, which is better
> > than nothing.
> >
> > Here's an updated patch that makes this change.  In addition, I
> > discovered that (1) the build succeeds and produces the same JAR
> > file even when I removed java-aqute-libg as an input, so I've
> > removed that, and (2) the build succeeds and produces the same JAR
> > file even when I use a dummy value for the biz.aQute.bnd.path Ant
> > property, so I did that to make it clear that it wasn't important
> > to the build.  What do you think?
> >
> > I think this is ok. I also noticed, that a dummy value would do,
> > but I had  
> no policy
> at hand about what to do in this case.
> 
> Actually I am not sure, that bnd is used runtime. How could we check
> that?

Try to run it when bnd is not in the CLASSPATH?

There's a method to get references to a dependency in java: you can put
it in the MANIFEST.MF file as:

Class-Path: /gnu/store/...

It's a space-separated list of jar files that have to be added to the
classpath. This could be done in a phase that runs just before the
build phase, like the phase that adds a Main-Class.

> 
> 
> > --
> > Chris
> >  

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.