[fedora-java] Re: Mending the Java native library mess before F10
Fernando Nasser <fnasser-H+wXaHxf7aLQT0dZR+AlfA(a)public.gmane.org>
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.
>