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 ?
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
