[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: j2sdk build-depends cannot be satisfied?



On Sat, Nov 16, 2002 at 03:12:52AM -0600, Kenneth Pronovici wrote:
> [I think this is still topical to both debian-mentors and debian-java.
> Someone tell me if they want it moved to one or the other...]
> 
> > gcj is supposed to come with a working jni implementation and comes with
> > gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> > doesn't work with gcj? Could you please file a bug report?
> > http://gcc.gnu.org/bugs.html
> > That way we at least know about the issue.
> > 
> > Also Kaffe, Kissme and SableVM (all part of Debian now) should be able
> > to run java byte code and jni code.
> 
> Wow.  I'm fairly impressed.  It didn't take a lot of screwing around to
> make this work.  I had to go with gcj-3.2, and that forced me to go with
> gcc-3.2 as well, and then I used fastjar to build the jarfiles.  I
> attempted to use gjdoc for Javadoc, with only limited success (more on
> that later).  Anyway, I'm glad you suggested that I look into this. :-)
> 
> The gij java runtime would not work for my test case (just some simple
> server/client pairs that come with the nbio distribution) but the kaffe
> runtime did work.  I haven't yet tried the SableVM runtime.  
> 
> The error I got from gij (below my signature) it a little out of my
> league.  I'm not exactly sure what bug I would file... perhaps you can
> make a suggestion?  I'd be happy to do some more digging if you think
> it's worth it.
> 
> I have several more questions now (I guess these are debian-mentors
> questions):
> 
> I'd like to distribute the Javadoc documentation with the package, but
> gjdoc doesn't seem to be quite up to the task yet.  I don't know of
> another free Javadoc tool.  I've thought that maybe I could pre-generate
> the Javadoc documentation using the non-free tool, and include it
> in the source distribution as part of the diff.  This way, I won't
> need to depend on a non-free tool to generate documentation that won't
> change after I build the package, anyway.  I'm not sure what stance
> policy takes on things like this.  Good idea?  Bad idea?

Well, i would separate the docs into their own package (nbio-doc) and
have them built and put into contrib (if you have right to modify them,
non-free if not). I don't really know, but i guess that if nbio builds
with free tool, it could even go into main, and it would be a shame to
hold that back just for the docs.

> Since I now need gcc-3.2 to make this work, I believe it's proper to
> list gcc-3.2 as a Build-Depends, at least until it's the default and is
> available on all architectures.  Is this correct?
> 
> In the original version of my package, I just listed a Depends on
> java-common.  Is this still appropriate, even though I know that not
> every package that provides java-common will work with my package?

You should list the working package first :

  working-java | java-common

This way, the autobuilders will pick the first option first.

> Thanks, all of you, for the help.  Sorry if I'm rambling.  It's 3:00am
> and I should stop hacking and go to bed. :-)

good night then, but i think nights are the best hack times.

Friendly,

Sven Luther



Reply to: