Bill Wohler wrote:
I see. By that same reasoning, you'd also put /lib/libc.so.6 in say, fileutils? ;-)
No, but libc6 contains also some binaries because it makes no sense to seperate the binaries from the library (each package would depend on the other).
2. placing both the script, if any, and the jar in libfoo-java.
That's exactly what libc6 did if you want to use that example.
3. placing the jar in libfoo-java and the script in foo.
This makes no sense at all as I have already outlined in my previous mail.
I don't care much if the package is named libjunit-java or junit, but I prefer to name application packages (binaries are applications) like the application itself. It's just important that there's only one package containing both the script and the jar.
The only time you'd put a jar in a package named foo is if you would never, ever, use the jar directly. That is, the only one in the entire world that uses the jar is the script. This is definitely NOT the case with junit. Also, we have a precedent for placing jars in libfoo-java. It would be as if all the programs depended on fileutils instead of libc6. I don't think #1 is a great solution.
Why can't you include junit.jar in your classpath if the package is called "junit"? You can simply depend on junit instead of libjunit-java.
I would be surprised if sticking the script in libfoo-java would have any precedent at all, so I think we can certainly rule out #2.
Why? As stated above, there are also binaries in libc6.
Thus, I think I'd lean towards #3. How bad of a problem can this be?
It's not a problem but more a redundancy and package bloat. Why would you want to seperate them? Do you really care about some more bytes in a shell script in /usr/bin/ if you want to install a jar with 100+ KB? You gain absolutely nothing from two packages "junit" and "libjunit-java".
So with your suggestion, I would have to split tomcat in at least 3 packages because some other applications might use an embedded Tomcat, e.g. JBoss or Enhydra?
-- Stefan Gybas
