Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> First of all, I will apologise for some of my heated 'answer round'
> during the last days. I still can't aggre completly with your (and
> others) objections, but I see that nothing won't change your opinion
> either :) so I try to find a *working* compromise.
Thanks a lot for keeping the discussion constructive. With the weather going
colder again in Germany, I am not going to complain about a little heat here
and there ;)
> I'm currently learning for a exam, so don't expect some bigger 'answer
> round' or a updated proposal during the next two days. I'll be back on
> friday evening or the weekend...
Good luck for your exam, I'm looking forward for a new round of discussion next
week.
> * Dalibor Topic wrote:
> >Great, then if you've tested it you can make your package depend on IBM's
> java
> >and Sun;s java as well and make the lifes of those users who prefer to use
> >IBM's or Sun's java easier. Where is the problem?
>
> The problem is, that IBM Java isn't packaged and so you can't
> 'Depends:' or 'Conflicts:' on it. Thats why I wanted the virtual
> packages, so that this is specified as the 'name to use'
>
> As I see, that you (you as in 'you and others' :) won't accept a
> virtual package for *all* the 'sun derived' JVM, I try a different
> approach: Give IBM, BD and SUN '*-bin' downloads a specific name. This
> could be done by asking the mpkg-j2sdk author to make the package
> names vendor specific and something more official (a.k.a "somwhere
> wriiten down" and "not chnaging ever other build"). Maybe it would
> even be possible to include it more tightly with java-common.
I think that's a very good idea, as it clarifies what VMs are installed on a
system.
> This will mean, that 'java*-runtime', 'java-virtual-machine',
> java*-compiler will become completly useless, as all package would
> 'Depends:' on the tested packages and not on the unspecific 'virtual
> package'.
Great!
> I will also try to implement a prototype of the 'findjava' skript.
Yes, please do!
> Usage as follows:
>
> * will 'echo' the full name to a 'java binary' pluss some VM args, so
> should be used like
> |JAVCMD=`findjava <options>`
> This will give you the posebility to react to this choice (like
> adding some jar to the CP or giving VM specific switches). The VM
> args will be specified by the user or by the packager and will
> include mostly things to tune some internal behaviour (IBM java and
> eclipse is better with some JIT specific switches)
> * <OPTIONS> will be include a list of packagenames (much like
> 'java-config''), which are tested and found able to run the package.
> * findjava will return the 'java binary' and the options based on:
> o 'force overwrite' option of the user
> o one of the specified java binaries (specified by package name),
> based on:
> . User specified preferences, if the users preference is include
> in the list.
> . some other preferneces given by other options
> . order of the list.
> o exit 1 in case no 'java binary' can be found
> * other options as I find some use for them, like --server or --client
> VM, which will automagically choose a 'able' VM before a 'unable'
> and includes this args for the VM, if 'able'.
> Any others?
I don't know how much of the VM options can be safely specified in such an
interface. I guess the easiest way is to add a switch -J<some vm specific
option> that passes the option to the VM without specifying anything about the
options the VM understands.
> This all will mean that some parts of the current proposal will be
> still almost the same:
>
> * the 'ant environment' specification is still intact, only the
> 'unfree interface' will be split into more packages, one for each
> 'unfree VM'. I hope this will be possible to with mpkg-j2sdk. I only
> would like to include the bootclasspath here, as it would make the
> 'jikes-something' adapter unessesary.
I don't think requiring in the ant environment bootclasspath is desirable, as
it requires a java 1.3+ VM, and a lot of code that uses ant to build can build
on a lower VM and doesn't need to mess with the bootclasspath. I'd prefer to
treat eclipse as an exception, not as a rule in this case ;)
> So, now my only question is still: what will be the agreed upon
> reaction to me filling bugs about 'include ibm-java (version) in your
> dependency, as it works'? I'm not happy (still) if I have to download
> more packages than nessesary and I would like to know what are the
> options for me, if a packager will just say 'its unfree, I will not
> include it'.
I don't think you could force a maintainer to include a VM in his package list,
as you can't force packagers to trust people ('so it works, eh? did you run the
regression tests? can I have the result files?'), but the policy should
encourage the packagers to work with their users and the upstream to provide
support for as many VM enviroments as possible, through relying on
co-maintainers, and knowledgeable users to handle those VM environments they
have no access to.
Of course, this depends how strictly defined the co-maintainer status is, i.e.
can you be a co-maintainer/test dude without being a debian developer?
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: