itz> If you permit an outsider to intrude... :)
Ola> What did you mean with this?
Java is not my cup of tea (coffee?), or at least hasn't been up to
now. I am interested in it, but I really don't like the
incompatibility of diverse JVMs and consequent uncertainty about
dependencies (and even freedom status) of Java code.
itz> Why must all lib*-java packages depend on java-virtual-machine?
itz> gcj is supposed to be able to compile class files into native
itz> code, isn't it? So these class libraries are, in theory, usable
itz> by people who just use them for gcj based develompent and link
itz> them into their executables.
Ola> You are right. The policy was written when gcj was in _early_
Ola> stages.
Ola> It should recommend (or at least suggest) a java-virtual-machine
Ola> though. Or simply depend on java-common which should take care of
Ola> that.
Ola> Actually I'm thinking of splitting java-common in three. *
Ola> java-common (which should provide some help scripts and suggest
Ola> or depend on things). * java-policy (With the policy). *
Ola> java-faq (with the faq).
Ola> What do you think about that?
Yes, I think this makes sense:
depends recommends
libfoo-java -> java-common -> java-virtual-machine
--
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
