Fernando Nasser <fnasser-H+wXaHxf7aLQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
writes:
> Can't we have the real JAR and the .so in %{_libdir}/%{name} as
> required by the guideline and add a symlink to the JAR (only) in
> /usr/share/java ?
No, since this would cause ambiguity in the multilib case. Part of
solving the arch-specific JAR problem is having the JPackage wrapper
scripts resolve %{_libdir} based on whether the app will run on a 32-bit
or 64-bit JVM.
Tom
> P.S.: This will get worse with the increase of maven use by projects
> as it is more strict where the dependency "artifacts" are located.
> You could perhaps change build-classpath to look at other places but
> it will e harder with maven.
>
> David Walluck wrote:
>> Thomas Fitzsimmons wrote:
>>> OK, which packages are these errors affecting? You could add the
>>> libreadline-java jar to CLASSPATH after the build-classpath invocation.
>>
>> Only libreadline-java is affected right now since that's the only
>> package that I found adhering to the policy.
>>
>> So far, all the packages fail in one of two ways: either the package
>> doesn't work with build-classpath, or it doesn't adhere to the
>> policy.
>>
>>> In any case I don't think you should change libreadline-java to not
>>> follow the packaging guidelines, if that's what you were planning.
>>
>> I would tend to agree, but the tools have not been updated to
>> support this configuration. The choice seems to be to change either
>> the tools or any of the packages to conform to the packaging
>> guidelines.
>>
>> As it stands now, I am more concerned with breaking existing
>> build-classpath invocations then following the policy since F10 is
>> almost frozen and nothing is consistent.
>>
>> Left as-is, you will just get four packages with four different
>> policies, and some of these may break existing builds or scripts.
>>
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
