Re: [Cp-tools-discuss] packaging cp-tools for debian

[Mark Wielaard]

Hi,

On Tue, 2002-08-13 at 22:53, Brian Jones wrote:
> Grzegorz Prokopski <address@hidden> writes:
> 
> > There was recent discussion about com.sun.javadoc. The problem was,
> > that this stuff is not licensed under GPL+linking exception like
> > all GNU Classpath is suppossed to be. It was suggested (not for the
> > first time) that this part doesn't really belongs to gnu classpath,
> > but it'd better be moved to cp-tools/gjdoc, where it is really used
> > and where it belongs.
> > http://mail.gnu.org/pipermail/classpath/2002-August/002499.html
> > I belive I've read some older discussion about moving javadoc
> > stuff to cp-tools project (don't have link ATM).
> 
> Yes, I forget who asked about this recently but I gave full permission
> to move the com.sun... interfaces for javadoc into cp-tools.

Thanks I had missed that. I will move the stuff later this week or the
next weekend then.

> > Some technical questions (if you want to give me some advice):
> > - ATM I have created separate packages for cp-tools (javap, javah,
> > serialver) and separate for gjdoc. Do you think that it is right?
> > Maybe it would be better to have just one classpath-tools
> > package with ALL this stuff in it? what about automakejar then?
> > what about texinfo-doclet? should they all be in ONE package?

Not all tools are developed at the same speed and none has had a
official release yet but I think your current division is fine.
I would keep automakejar and the texinfo-doclet separate at the moment
till we find out how to proceed with them.

BTW Classpath proper also contains an rmic implementation (look at
gnu/java/rmi/rmic/RMIC.java) and since libgcj is being merged with
Classpath they also include it (I believe it is already packaged in the
gcj-3.2 package which just entered Debian unstable).

I also still want to write a jar tool in java but that has very low
priority since we already have fastjar (also bundled with gcj I
believe). But most security/certificate classes are now in place in
Classpath except for some jar verification in java.util.jar and then it
might be a good idea to write a jarsigner tool.

> > - I needed some names for javap, javah i serialver, so I added
> > cp- prefix (cp-$origname) and put it into /usr/bin/
> > do you think it is OK?
> > - oh - and I couldn't get gjdoc Makefile working, so I just
> > jikes `find . -name \*.java`
> > fastjar `find . -name \*.class`
> > Any objections?
> 
> I believe Debian is fond of creating some weirdness in /etc and
> /usr/bin such that if you install more than one version of 'vi' for
> instance that you can configure to a particular version.  That is
> probably how these tools should be viewed as well is my guess.  On my
> system, I would rather they had the traditional names of javah, javap,
> javadoc, but these can just be shell script wrappers for whatever.

The weirdness you talk about is the alternatives system and it is great!
Since gcj also contains some of these tools but with different
names/implementations (and they sometimes take different argument flags
-  so you might need to create wrapper scripts for them) I think it
would be a good idea to give these tools distinctive names by adding cp-
or gcp- in front of them as long as you set it up so that I can just use
update-alternatives to select the version I want.

It would also make sense to create native binaries versions of these
tools with gcj that version can then be used regardless of the
particular JVM that the user has installed.

Cheers,

Mark

Cheers,

Mark