Something needs to be explained about how debian packaging works. It will
help with the understanding of a few things below.
Debian source packages contain 3 files(normally)
1: A tarball
This tarball is generally an unmodified upstream release, except that it is
renamed.
2: A diff
This diff contains modifications done to the upstream source, plus the
files in debian/, that say how the debs should be layed out.
3: A .dsc
This is a simple text file, that describes meta data about the source
package.
The tarball is prefered to be unmodified, so that md5sums can match with what
upstream has.
The modifications done to upstream is generally supposed to be minor. If
something major is done, or bug fixes where done, then these should be sent
upstream.
On Thu, 15 Nov 2001, Jason Dillon wrote:
> > Does the stuff in j2ee and naming depend on other jboss items? Do they depend
> > on the jboss module? If no, then I started at the wrong spot.
>
> If you look in each build.xml there is a target called '_configure-modules',
> this section shows the dependency on other modules (or in the case of the
> build module shows how the modules are organized).
Ah, this is very useful information. For any splitting I end up doing, this
will help me greatly.
> > Is everything in thirdparty exact copies of external libraries, that get
> > built, or just checked in pre-compiled version, or a mixture of the two?
>
> 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.
Please see my forthcoming mail, explaining this(I didn't want to include it in
this mail, because it would make it too cluttered).
> > In either case, since they are third party modules, and not part of jboss,
> > they can not be packaged with jboss in Debian.
>
> 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)?
> > If jboss has patched these upstream sources, have the patches then been sent
> > upstream?
>
> Nothing in thirdparty has been patched. They are the same files from
> downloaded distributions.
Good.
> > I'm not building a single jboss deb. What I have done for 2.4, is make
> > separate debs, split along the same lines as each top-level directory in the
> > 2.4.3 tarball.
>
> I am not interested in the .deb'ification of 2.4.x at all. I would expect
> that the package structure of 2.4 would be mostly if not completly different
> than 3.0.
Because 3.0 is imminent, I won't be releasing the debs of 2.4 to a wide
audience. Those who will see it, are people here at work, and a few
interested Debian developers, who are also interested in JBoss. I am using
these people as my alpha and beta testers, so I can make sure that the Debian
packaging is correct and functional.
> * * *
>
> 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.
Also, there is not a single type Debian user. It is true, that doing
something along the lines of 'apt-get install jboss' should give you an almost
exact copy of what you would get when downloading a precompiled JBoss tarball.
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.
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.
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?
If these dependencies were part of the deb, then the package would not
install/configure, until all of its dependencies were also installed and
configured.
> 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.
> 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.
> If these maintence problems are not resolved, then each time a new release
> comes out there will be problems when users upgrade, which might lead them
> away from JBoss... or may lead them to simply download the .tar.gz and work
> from there (which isn't soo bad, but just wasted yours and my time over all
> of this).
This is another thing that Debian does quite well: In place upgrading, without
lose of configuration, or introduction of breakage.
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.
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,
2: The new version can install, but not start up automatically.
3: The new version can actually be packaged as a separate deb, with a
different name, so that there is no 'upgrade' per se.
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.
> The only way I can see that this will fly at all would be if
>
> 1) the building of jboss .deb's was integrated into the jboss build system
> (removing the dependency on you or any other .deb packager to build them)
This is an eventual goal.
> 2) proving that there are active/reliable maintainers of packages
> for ALL the thirdparty libs required or generating those libs from the
> jboss thirdparty repository
Debian has facilities for handling MIA maintainers.
> 3) ensureing that any FHS or anyother debian specific changes that need to
> be made to the release do not have ANY effect on the servers operation
> and do not make the administration and support of the server any
> different than the .tar.gz/.zip release.
This is the role of the Debian maintainer. If the maintainer does modify the
source, then he is committing 'bad mojo'.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
