I am creating .deb
installation packages for our software, which has a dependency on tomcat7
. Unfortunately, this package is not present in Debian squeeze, which ships only with the package tomcat6
.
The upcoming release of Debian 7 (Wheezy) ships with both Tomcat 6 and 7. Does that mean I can take the source package from Wheezy, rebuild it for Squeeze and put it in our custom repository along with builds of our own software? Or will this be likely to result in conflicts on Squeeze systems somehow?
There are instructions on several places how to backport tomcat, however what worries me is that Tomcat 7 is not part of the official Debian 6 backports project. I don't want to mess up the systems of any of our users. For example if they try to install our software on a system that already has tomcat6
installed, which I think conflicts with tomcat7
. In that case it should resolve this gracefully in the same manner as would happen on Wheezy or Ubuntu.
Best Answer
From the link you show, the backport of Tomcat7 seems easy, indeed. And if all works well you should end up with a tomcat7 package that fulfills your requirements. But...
It might have worked back a year ago (when the blog post appeared) but now I think there is a catch. Actually, the step
apt-get build-dep tomcat6
is a bit tricky. What should really be done isapt-get build-dep tomcat7
. Once you try to do that, you'll see that the work is a bit more tedious. A few other packages will come up as build dependencies and you'll need to install them, if they are available, or build them from sources if not.Build process
From my trials, I've find that to be able to build
tomcat7
for your users, you need to:maven-repo-helper
andjavahelper
,jakarta-taglibs-standard
and install it on your build machine.At the end, the whole procedure as I've done it looked like (version numbers provided as of 06/03/2013):
Peculiarity of tomcat7 7.0.28 source package
The listed instructions above should be all that's needed. However, there is an expired certificate in the
tomcat7 7.0.28-4
source package in the Wheezy/testing repository (a self signed certificate expired on Feb 27th 2013). This will make the build failed in the unit tests.There are 2 solutions to solve that:
disable the unit test for your build, this can be done in the
build.properties.default
file, you'll need to change the 3 properties:execute.test.bio=false
execute.test.nio=false
execute.test.apr=false
Installation
As you've seen in your link, you will come with a few
tomcat7-...
packages that you'll need to provide for your users. The best would be through your own repository so they can install all that easily.With all those packages, all should be ok and your users will actually have a backport of Tomcat 7 to Squeeze. If your users then migrate to Wheezy, they should have no issue as any new Tomcat 7 package in Wheezy will have a bigger version number than the one you've provided them. They'll receive the Wheezy upgrades just fine.
Maintenance
One last thing you need to consider are the Tomcat 7 security or bug fixes that comes into Wheezy later on. If a serious
tomcat7
update pops up in Wheezy, you should really consider rebuilding your owntomcat7
packages and provide those same updates to your users.