Packages from Repositories vs up-to-date packages

The reason we install OTRS from the package manager is that it's easier to maintain software that way and you get a well tested, stable version that is often also supported with security updates which are safe to install automatically - because they only backport the security fix itself with no other changes that could break your deployment.

The downside of course is that you don't get the latest version for upstream. It's a compromise.

We would consider including the upstream version of OTRS in future versions of the appliance if OTRS could somehow update itself safely without relying on the package management system. WordPress does that now, so the WordPress appliance includes the latest version from upstream.

An alternative route would be to maintain your own security updates repository for specific versions. Providing new versions isn't enough as it's unstable. You would need to commit to providing packages with backported security fixes to a version once you release it. You could either do it in-house or maybe sponsor the work done by the Debian OTRS maintainer. If there's a new version in a stable supported version of the OTRS package in Debian, we might use that instead of the version in Ubuntu.

Mike, I've learned the hard way that you have to be very careful before you consider breaking Debian packaging rules because you can easily screw things up that way. For example, if OTRS includes its own package management system, that could conflict with the Debian package management system in unexpected ways. If so, it may be better to redesign that part of OTRS to leverage the regular package management system somehow. At least on Debian/Ubuntu. There is rarely a good reason to break packaging policies, especially if you don't fully appreciate the ramifications. It may require more work on your end but there should be a way to achieve your all of your goals without breaking "the law".

We're not too eager to diverge from the Debian OTRS package, especially if your package implements its own package management system in a way that violates the Debian Policy Manual.

We would be open to using your PPA as the source for OTRS if:

1. You can produce a package that doesn't violate packaging policy in a potentially harmful way.
2. You could commit to backporting security updates the way Debian does.

Again, the main advantage of using a Debian package in the stable distribution is that the Debian security team have committed to backporting security fixes to the version that was shipped with the release. This policy is what makes it safe for us to configure an appliance to auto-install packages from Debian's security updates repository.

So, I'm still puzzled? What would be the actual advice here?

We provide security updates for up to four minor versions. We don't have security issues often, but fot the last one we released patches for 2.1, 2.2, 2.3 and 2.4. We create a new minor release version (aka 2.4.x) but also just point to the actual diffs for the fix.

As I pointed out, debian Testing currently has the latest version of OTRS, just as Lucid. But whenever we release the next version of OTRS, we will have the same problem again.

Also, there's an issue with the way Debian handles files, and the way we do it. One of the most powerful features in OTRS is the package manager. You can install additional functionality such as a knowledge base, or an integration with a system monitoring system such as Nagios or OpenNMS by installing it from our web based repositories. On Debian, this is broken because of the fact that privileges have to be raised to a level Debian does not allow. Of course, for the regular package on my server I can understand this, but for the main package on my server, in this case OTRS, it is not really helpful. The debian Wordpress package also suffers from a broken plugin management, and disfunctional attachments upload, because of the same reason.

This might be yet another reason to switch away from the OTRS package to something else. So my question is, would you think it would be a viable option if we create a PPA for OTRS and you use that to get OTRS on the TurnKey appliance?

Regards,

Mike.

So each appliance is considered separately.

The reasons for choosing to install from upstream vary. In some cases the repo versions are so far out of date that they are missing in features to the point that they are not fulfilling the needs of the community; occasionally a repo version of a package is a bit buggy, or doesn't work that well with other software included (Moodle with php5.3 springs to mind here) or that like you say WordPress has an internal update mechanism that is sufficently robust and the additional features are sufficently desireable.

So it's not that non repo versions as 'bad' as such it's just that it's not a decision that can (or at least should) be made lightly, and the full implications need to be thought through before a decision to deviate from the repo version is made.

And by my understanding; the point that Liraz makes, is not that 'going outside of the distribution's package system is "a bad thing"'. AFAIK, non-package management updates can be ok, but they need to be done carefully and not conflict with Debain package management policy.