On Thu, 15 Nov 2001, Jason Dillon wrote: > Hopefully the installed .jars will have some version number seperation (like > jaxp v1.0.1 vs jaxp v1.1) otherwise you will end up with version > incompatiblities.
For minor changes in a 'library', a new upload can replace existing files. For major changes(1.0 -> 2.0, or possible 1.1 -> 1.2), then a new package is supposed to be created, so that both packages can be installed at the same time. The Debian java policy is still being ironed out, but in the case where there is a jaxp1.deb and jaxp1.1.deb, there would also be a symlink jaxp.jar -> jaxp-<ver>.jar. > Also, you will be signing yourself up to maintain these, if there is not a > active reliable maintainer for them already. I'm for that. > No other Debian package will depend ong jboss-j2ee... or rather no other > package should depend on jboss-j2ee. If a package is dependent on jboss it > should depend on the entire jboss package or the client package (or > appropriant client package as you slice them up). Of course, currently, there is no j2ee environment at all in Debian, so having this as a separate deb doesn't quite make sense right now. > > That's what I did for my first version of 2.4.3 debs. I then split it into > > multiple. > > What do you gain from splitting them up? If each deb matches a single(or group of) services, and they are not nescessary for jboss to work, having them not installed by default, makes sense. There will always be some deb, that depends on the entire kitchen sink, so that it is easy to get jboss working, just like it does upstream. > I could see that it might be easy to build packages out of one cvs module > (client, doc & whatever packages too), but I don't see how that buys > anything for either the developer or users standpoint. There are developers, users, and admins. It's the admin view that splitting debs up helps. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
