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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
