> 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.
Good. > > 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. Good... though it would be best if your maintained them as part of the build system, or an optional module of the build system which maintained these... just in case something happens (like you get bored...). > > 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. jboss-j2ee is basically the interfaces you can get from sun. they were re-written to avoid licensing issues. > > 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 get it... just don't go crazy splitting things up too much. > > 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. In this case the user is the admin. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
