I'm not sure about jython (haven't looked), but optional.jar has theI think the dependency on junit sort of makes sense since it can be considered a basic tool for java developers. The same cannot be said of jython and antlr.
glue for junit (->junit task). Junit knows nothing about ant.
AFAIK the junit task is in the optional.jar.Agreed with that. The change concerned jython and antlr.
I don't see the problem from the user's point of view. If he wants to use ant for development, he will 'apt-get install ant'.What you suggests is 'could beThe difference is that no 'glue' is needed for a Makefile to make use of a program.
used from make programms' Suggests: make.
Yes, thats true. Only that a user won't know the difference...
Not necessarily. For instance, I am packaging a compiler, that happens to include a ant task. It's not its main purpose, just a additional feature.This is already done: ant dows provide all tasks in optional.jar andAre you implying that only ant is supposed to provide ant tasks?
IMO, it shouldn't Suggests: ant :)
No, but all other packages will have mostly one purpose: adding a
task. For them to Depends: on ant would be kind of natural.
[splitting optional.jar]I'm not asking for the upstream ant to be broken into pieces, because I agree it would be lots of work. if somebody wants to do it, fine!
It's a possible design, which sounds ok to me. Alternatively, what would be wrong with including the task in the package that provides the underlying facility?
Nothing, but it's quite a task to coordinate that or even provide
pacthes for upstream and telling apache ants people to stop including
that tak in there distribution...
We have the same problem (optional.jar surely will not compile withoutI'm fine with ant Depends junit, but not jython or antlr. Ant could Build-depend on them, of course.
junit installed), but we distribute binary packages, so we could add
only suggests and the actual packages, which use the task could
Depends: on the 'functionality' package. gentoo doesn't have that
option, as they build from source...
Regarding the symlinks, I think they rather belong to jyton and antlr, as this makes sure they are not dangling. However I'm fine with the original solution too (have them in ant). Dangling symlinks are not a policy violation or
Anyway, the more I have to do with java packaging, the more braindeadNow, don't be pessimistic! There _has_ to be a way to do things right ;-)
it seems to me...
Daniel
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
