On 2001.11.15 18:06:11 -0500 Jason Dillon wrote: > > > 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?
No, the point is to make sure mbeans aren't started before their dependencies are satisified. There's no time limit on when someone might come along and deploy the needed mbean. > > 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? I cannot imagine why anyone would not want the entire jboss distribution. Its easy enough (almost) in 3 to set up the components you want by putting them in appropriate directories or (soon) writing a deployment script. This isn't big enough to support the extra confusion of splitting into more than one piece. > > 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. The official line is that upgrading from 2.x to 3 must be done by hand. I wrote a transitional mbean that translated from XADataSourceLoader mbeans (2.x style) to ConnectionFactoryLoader mbeans (3.0 style, very different configuration) and marc asked me to take it out. I think that was a good choice. The configuration files for 2.x and 3. are so very different this really needs careful thought. A script translation is impractical and a waste of time. just my 2c david jencks > > --jason > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
