Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Stefan,
* Stefan Gybas wrote:
>Your proposal is a complete rewrite of the Java Policy but I think this
>step is too big: You have changed a lot of requirements that have been
>discussed in the past but there has not been a consesus. For example,
>you have changed the naming of library JARs from the package version to
>the API version and you have removed the possibility to put Java classes
>in /usr/bin (using binfmt_misc) whithout mentioning this change (or I
>have missed it).
The reason for the binfmt_misc change:
apt-cache showpkg binfmt-support
[...]
Reverse Depends:
wine,binfmt-support 1.1.2
wine,binfmt-support
>While I agree with both changes, they should be in
>separate proposals (via bugs against the java-common package).
Yes, I probably will put up some bugreports, when there is some sort
of consensus. I'm more for discussin the general direction here in the
ML and then after that doing the rest in bugreports, even if the
bugreports are mirrored into the ML.
>I also like the idea of specifing the directory layout for packages that
>provide a virtual machine, e.g. bin/java. What I don't like are your
>proposed changes to Ant to support different versions of e.g. javadoc. I
>don't want to maintain a forked package, all changes from upstream will
>IMHO cause just confusion for the end users.
See the third proposal. IMO there are no changes to ANT, but only to
your CDBS classes (to pickup the 'ant environment' variables) and to
the actual 'ant environment' packages. The goal of the third version
of the proposal was to make sure that ant will work out of the box.
I also don't see the need to fork debian/ant from upstream/ant.
IMO this proposal will be easily adaptable to a new ant, which will
use a delegate system for javadoc like for javac, if that will happen.
>So I suggest that you file bug reports for the individual changes you
>want to make. I have uploaded a new version of the java-common package
>which has the maintainer set to this mailing list. This means that all
>bug reports with proposed changes will automatically go to the mailing
>list for discussion.
I will do that after there is a sort of consensus. I'm also not sure,
whether it is possible to split this proposal into seperate
bugreports. Alsmost all sections have been rewritten and are based on
each other, as the virtual package names have changed.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: