On Wed, Oct 15, 2008 at 4:43 PM, David Walluck <david(a)zarb.org> 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.
--
Sincerely,
David Walluck
<david(a)zarb.org>
--
fedora-devel-java-list mailing list
fedora-devel-java-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
As a consumer of these packages, particularly tanukiwrapper, I prefer
the jar lives in /usr/share/java/ and the
JNI library live in /usr/lib(64). It's nice to know where ALL of the
jar files live. Having to determine if a jar
is native or not and determine whether to look in /usr/lib,
/usr/lib64, or /usr/share/java seems a bit annoying.
If you look at it from the java side, a developer will put the jar
file with all of their other jars. Then put the
library in the platform specific location. So putting the jars in
/usr/share/java really fits inline with this.
Sorry, just offering my 2 cents as a user :) /me didn't realize there
was already policy to do the contrary, I
would've spoke up then.
Sincerely,
jesus rodriguez