2

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.

2
  • Is there any reason why you do not take the binary version for Tomcat7? In that case only java matters without need to recompile or backporting.
    – Nils
    Mar 6, 2013 at 10:45
  • I want to stick with the package manager, and not require my users to manually install and configure software. This has resulted in a lot of conflicts in the past. Mar 6, 2013 at 17:15

1 Answer 1

1
+50

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 is apt-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 tomcat7for your users, you need to:

  • enable squeeze-backports and install from there maven-repo-helper and javahelper,
  • build from wheezy sources 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):

# adding wheezy sources to your apt config and preparing the build host:
echo "deb http://backports.debian.org/debian-backports squeeze-backports main" >> /etc/apt/sources.list
echo "deb-src http://ftp.debian.org/debian/ wheezy main" >> /etc/apt/sources.list
apt-get update
apt-get install dpkg-dev build-essential fakeroot
# manually adding missing build dependencies
apt-get -t squeeze-backports install javahelper maven-repo-helper
# getting the source package for jakarta-taglibs-standard, building and installing it on the build machine:
cd /usr/local/src/
apt-get -t wheezy source jakarta-taglibs-standard
apt-get build-dep jakarta-taglibs-standard
cd jakarta-taglibs-standard-1.1.2
dpkg-buildpackage -rfakeroot -b
cd ..
dpkg -i libjstl1.1-java_1.1.2-2_all.deb
dpkg -i libjakarta-taglibs-standard-java_1.1.2-2_all.deb
# getting the source package for tomcat7 and building it (this takes some time...)
apt-get -t wheezy source tomcat7
apt-get build-dep tomcat7
cd tomcat7-7.0.28
dpkg-buildpackage -rfakeroot -b

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:

  • change the date on your build machine to be before Feb 27th 2013,
  • 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 own tomcat7 packages and provide those same updates to your users.

2
  • Thank you for this very complete answer. It seems strange that the certificate in the package is expired. Should we report this to the Debian wheezy release team? Also, do you have any guess on why Debian isn't providing jakarta-taglibs-standard and tomcat7 in their squeeze-backports repository? Mar 6, 2013 at 22:08
  • I think the expired certificate is only used for the unit tests, so I'm not sure if this is considered an issue by the Debian Tomcat maintainers. We could check with them though. I'm unsure why they don't provide this package in the squeeze-backports repo, it might only be that they're waiting for someone to actually propose it.
    – Lætitia
    Mar 7, 2013 at 10:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .