> I 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.
On the other hand, having jython depend on (or recommend or suggest) ant is quite nonsensical as well, since ant is not really a tool for script writers - in fact jython is not enhanced by ant at all. The relationship works the other way around: jython enhances the functionality of ant. So from a purely semantic point of view it seems that ant should provide the suggests/recommends/depends. > I'm fine with ant Depends junit, but not jython or antlr. Ant could > Build-depend on them, of course. Indeed there is no problem with ant build-depending on lots and lots of stuff. This will not affect the everyday user, who'll just be installing it. As for dangling symlinks, I'd be inclined to say don't worry about it. I have this situation in one of my own packages: kdbg provides a symlink to the KDE common directory for each of its translated languages. So (for instance) if kde-i18n-fr is not installed then kdbg has a dangling symlink. I can't possibly require every user to install the (very large) kde-i18n packages for each language that the kdbg docs are translated into. It's also not feasible for kde-i18n-fr to provide this symlink for every app that has French translations (for instance). So the symlink is just left dangling, and if a user is reading the French docs then they almost certainly have kde-i18n-fr installed so there is not actually a problem. > >Anyway, the more I have to do with java packaging, the more braindead > >it seems to me... > > Now, don't be pessimistic! There _has_ to be a way to do things right ;-) hehe.. I must say I also reached Jan's state of mind some time ago. :) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
