guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#29896] [PATCH] gnu: java-asm: Update to 6.0.


From: Gábor Boskovits
Subject: [bug#29896] [PATCH] gnu: java-asm: Update to 6.0.
Date: Sat, 20 Jan 2018 10:08:04 +0100

2018-01-20 8:50 GMT+01:00 Chris Marusich <address@hidden>:
Leo Famulari <address@hidden> 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 <address@hidden> writes:

> Chris Marusich <address@hidden> 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?
 
--
Chris


reply via email to

[Prev in Thread] Current Thread [Next in Thread]