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

Re: RFS: various packages



Matthew Johnson wrote:
> Well, I've several small (only a few classes) libraries with different
> purposes. I didn't think it was worth a separate source package for
> each, therefore there isn't really an overall purpose for the library as
> a whole. The _binary_ packages do have more appropriate names
> (libunixsocket-java, libcgi-java etc). The ones which are too generic
> and likely to clash are qualified with libmatthew$something-java because
> someone else said that calling mine libdebug-java would be likely to
> clash. I don't really know what else to do with the names.

Yes, I see what you mean, and I can't think of a better way to do it.
Can anyone else comment?

> 
> This is also why the versions are out of sync; I'd like to be able to
> keep track of the versions of each one separately, whereas the whole
> source also needs a version.

The Java Policy doesn't insist that the Jar's version number is the same
as the upstream version number, so you should be OK. But it does make me
wonder if you are making things a little too hard for yourself. My
feeling is that you would be better off with 3 independent upstream
tarballs and 3 source packages - even if each source package is quite
small. But that's just my personal opinion, based on little knowledge.

I've had a quick look at the package and have a couple more observations:

1)  There was recently a mass rebuild of the Debian archive to check
that packages did not leave cruft behind after a "clean". This involved
calling "debuild" twice. It looks as though your package would fail this
test (as did one of mine, bug #424089). I think you just need to delete
the doc directory.

2)  I'm not sure if you have seen the proposed new Java policy
(http://wiki.debian.org/Java/Draft)? It suggests that "java libraries
must not depend on any runtime".

3)  when I try building it I get:
	java.lang.NullPointerException
	   at
gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printClassPage(javadoc)

I'm not sure what's causing this (and it doesn't cause the build to
fail). Does it happen when you build it? I would guess this is an error
in gjdoc, possibly provoked by something a bit odd in your code. Is it
because your Debug.FilterCommand interface is marked as "static"?

4)  Lintian warning (Probably related to the previous point): W:
libmatthew-java-doc: zero-byte-file-in-doc-directory
usr/share/doc/libmatthew-java-doc/api/cx/ath/matthew/debug/Debug.FilterCommand.html

5)  Your binary packages do not have any "Section". I think the Javadocs
should be in Section: doc.

6)  The "-doc" package "Recommends" the other packages. I've normally
used the weaker "Suggests" for this relationship, but I'm not sure which
is right. Maybe someone else can comment?

Lastly, I meant to mention in my previous email (but forgot): I use your
Java CGI library on one of my systems, so thanks very much for writing it!

Thanks,
Paul



Reply to: