> > Everything from thirdparty and tools are pre-compiled. > > This is bad. If these were to be in the tarball that was used for building of > Debian packages, then the source package could not be uploaded to Debian.
Fine. Lets not upload a source package. > > Fine, as long as you make for sure that there are packages available that > > contains the *exact* version of these libraries (version appropriately so > > that things don't break when they are updated). > > Are the things in thirdparty and tools the latest available? Or are they > somewhat old, as making jboss work with newer versions would be too much work > right now(right now not precluding it will work later on)? Depends. They are the latest version that works with JBoss, or that has been tested to work with JBoss. In most cases they are the latest, but in some cases they are not. > > I am interested in the creation of .deb's to make it easier for people to > > get/install/use JBoss. I am very concerned that what you are doing will > > cause support and maintenece problems. I would rather like to avoid having > > differing instructions for debian and non-debian users. I would also like > > to avoid help me emails about users who have the wrong version of > > thirdparty .deb packages installed... especially when I don't really know > > who makes and maintains them. > > Well, for things that exist in thirdparty, there are already existing debs in > debian. I will make jboss depend on those debs, and modify build.xml to use > the system install versions, instead of the local versions. Are you SURE there is a package for the correct version of EACH ? > However, there are users more advanced than this, who may, for whatever > reasons they have, not want the full JBoss environment, and only install a > smaller set of features. This will not be supported, why waste time trying to rig up a package system to handle it? Advanced users will either make there own packages or abandon packages in this situation and trim down the release themselves. > The way this is accomplished, is with dependencies between debs. You have > mentioned that there is a '_configure-modules' target in the build.xmls, that > shows the dependencies. This information would be 'ported' to the Debian > dependency system, and would allow for micro installation of services. Again, the cvs module seperation is not meant as a functional or component seperation tool to generate these types of packages. These dependencies show which modules are required to build the given module... they don't show which modules you would need to do something usefull with it. > I've seen talk about 3.0 mbeans supporting 'dependencies' by using > mbean-refs(and lists). This information could be put into the .deb as well. > What happens when an mbean depends on another mbean, but isn't distributed > along side it? How is it installed onto the system? Does JBoss throw an > error when a mbean-ref doesn't exist? I am not sure, but this would be more along the lines from which you would want to seperate packages. > > I think it would be really cool if a debian user could 'apt-get jboss' and > > in a few minutes/seconds have a functional server which they could start > > working with right away. > > That's my goal. However, I do want to support the advanced users that know > more about JBoss, and want to fine tune the installation set. Ok. I consider myself an advanced user. I basically want the entire release. I suppose that I could live with out the cluster jars and such... but it seems like to cost involved with making those split ups is not worth it. If you are going to setup a .deb release system you need to think about the other users which may have to maintain your work. Lets not make things overly complicated if the pay off is not worth it. I do not think it is worth it here... unless you can keep it really simple. > > I also think that there are huge maintenece issues envolved with making this > > happen. Thus I would lean twords a .deb building system that took worked > > off our existing release and made use of the support files which are > > contained there. > > It will, except for most things in thirdparty and tools. Ok. How do you plan on solving this? This is a BIG issue. > Debian packages are designed so that when upgrading from one version to > another, the configuration is carried over. If, for some reason, the new > version of a package has a subtle change to the configuration, then generally > a script is written that facilitates this change. Ok, so now we have a script maintenence issue... perhaps one for each of the packages that have been split up... lots of them based on what I have read so far. This is only for advanced users, using debian or an apt-get compatible unix. What percent of the user/admin population does this cover? What percentage could live with a small set of larger grain packages? What percentage could live with a single package? Splitting them up is just not worth the effort. > Additionally, if the new version is so radically different that any kind of > automatic conversion is not possible, then a few solutions can be used: > > 1: The new version can either refuse to install, when it detects that the > existing configuration won't work; or, We don't want JBoss to "refuse to install". > Often, upstream developers don't always fully consider the issues that can > occur from upgrading from several different old version(2.2 -> 3.0, 2.4 -> > 3.0, 2.4.3 -> 3.0) to the latest. Quite often, there only exists support for > upgrading from the last released version. It is the Debian maintainer's job > to make sure that a package installed in Debian stable, can be upgraded to the > next Debian stable, 2 iterations later. It's not always appropriate for > upstream to consider this, as upstream is concerned about producing the best > possible piece of software. It's Debian's concern about upgrading. Each > entity knows their respective field. I would say that the maintenece from a 2.0 -> 2.2 -> 2.4 -> 3.0 is big enough with one single package. Multipule packages simply makes things exponentially more complicated. Keep it simple. You can't solve everyones problems... why try? At least start out simple. Lets get something integrated which handles the thridparty problems and builds one jboss.deb or a jboss.deb and a jboss-client.deb. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
