[pkg-kolab] Kolab Systems (ISV) requirements (was: cyrus-imapd 2.3.16)

[Philip Hands]

Hi Jeroen,

On Wed, 1 Sep 2010 15:49:21 +0200, "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com> wrote:
...
> Hi Mathieu!
> 
> Let me answer to the questions/answers separately, as to avoid obfuscating the 
> thread.
...
> For example, Kolab Systems may be required to support customer deployments of 
> kolab-2.3 series for a number of years, while nobody in the community cares 
> about it anymore some time after kolab-3.0 hits the fan.

If you care about it, then someone in the community cares about it.

We even have a section "oldlibs" specifically for library packages that
are obsolescent but which some packages still need to rely on for some
reason (generally ISV binaries that depend on that version of the
library, as Debian packages can just be rebuilt on the whole)

So, if you want to package old versions, as long as you do it in a way
that is policy compliant (which might involve renaming the package to
have the version number in it, say).  If you think it's useful for
that package to be in Debian, then you're probably right.  Very few
people's requirements are totally unique.

> On a related topic, Kolab Systems -inherent to it all being supported and 
> such- requires its own distribution channels; sometimes we may need to quickly 
> solve one or the other issue and can not allow ourselves the risk of being 
> held back by community distribution policies or access levels our engineers 
> may or may not have. On a related note, we cannot allow ourselves the risk of 
> a community member breaking our supported version of the product.

It would be entirely reasonable for you to add an additional APT source
on systems that you support, with /etc/apt/preferences indicating that
versions from your archive should be favoured even if higher numbered
versions are available from the Debian archive.

This would not require you to do anything that might be deemed
community-hostile.  You just put up an archive with the versions that
you prefer your customers to use, and the settings on their systems will
ensure that they use your versions.  If you patch the packages locally,
just add something like ~kolabsys.1 to the end of the version number.
The tilde(~) sorts below something with that bit missing, so if your
package makes it into the wild, it will not be used by other people by
mistake:   http://lwn.net/Articles/194664/

> Other times we have to release something that is not quite ready yet to what 
> is considered to be a stable distribution release -adjacent to unstable 
> distribution versions. We wouldn't want to burden the community members on the 
> receiving end of bugs with such volatility.
> 
> Another example would be, that for the Kolab product, we touch configuration 
> files from other packages. Most commonly, such is not allowed to be included 
> in native packages included in a distribution's package repositories.

Doing that is generally a mistaken approach to doing what you want.
It's generally better to either use something like puppet to control
the systems, or to make the bits of the packages that you want to
tweak something that can be selected in debconf at install time, and
then perhaps providing preseed values so that your preferred defaults get
applied automatically.

That way, all the people that agree with your alternative
configurations, have a nice way to deploy it, and can collaborate on
making the postinst work nicely, rather than the effort being fragmented
into dodgy, policy violating packages.

> Either way, however, this would all be related to Kolab Systems more so then 
> Debian specifically.

True, but over the years I've found that doing the apparently quick and
easy thing comes back and bites you in the end, so when you're tempted
to wander into policy violation, it's worth checking if there's not a
nice way of achieving the same thing, even if it takes a little more
effort up front.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-kolab-devel/attachments/20100903/955dd1bb/attachment.pgp>