On Mon, 2007-05-14 at 14:25 -0700, Daniel Ostrow wrote: > > We release our packages as upstream intends. If they don't split them, > we don't split them, talk to upstream not us.
Well that is not always the case. Not to contradict. We tend to make packages in the Java world that are subsets of a upstream package. In short it's because many upstreams bundle dependencies. So we will strip out those dependencies and maintain them as separate packages. Even though it was not really intended to be such by upstream. For example, take dev-java/servletapi ( really tomcat-servlet-api same sources, soon to be merged with virtual ... ). Many packages ship with a servlet-api.jar. That jar comes from Tomcat, but is not available as package on it's own. It's sources were in a separate CVS tree with its own build system, but as of Tomcat 6. That was merged into unified source tree and single build system. Upstream releases a project called Glassfish, that will eventually be many glassfish-* packages. Although due to the size Glassfish is broken up but there are not individual sources available per sub-project. JBoss is very similar, and many packages use JBoss modules. Like glassfish-jsf-api :) Mighty fun stuff. We do try to get with upstream were it's feasible. But really much if this is out of control in the Java world. I believe Maven is an attempt to reign in some level of control, manageability, and etc. Among other things. Granted all this might be unique to Java. Since applications developed in other languages, don't always have a binary release available. When one is, rarely do they ship all the libraries in binary format they need. But packages do get split up even though upstream does not really provide for such. I would not recommend doing it unless there is a reason and need like on the Java front. Sorry for length. -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
