Repos [Was: competition]

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at
Wed Sep 22 05:03:49 EDT 2010

Adam Tauno Williams wrote:
> On Tue, 2010-09-21 at 12:25 +0200, Syren Baran wrote:
> > Am Dienstag, den 21.09.2010, 11:48 +0200 schrieb André Schild:
> > > Am 21.09.2010 11:35, schrieb Simon Matter:
> > > >> I don't know, where this bad karma is coming from - I'm still happy
> > > >> with
> > > > 
> > > > I guess it's simply because for many years there were no clean
> > > > packages for the most used operating systems.
> > > 
> > > Debian is still stuck on 2.2 and there seems to be no progress in that
> > > area.
> > 
> > Most people like to use versions from repositories. For obvious reasons.
> > Might make sense for cyrus to host their own repository. If it's just a
> > simple entry in sources.list(.d) more people would use the recent
> > version.
> The OBS supports just about every distro there is;  why not host there?

It'll build *something* for all distributions, but it does definitely not 
*support* all distributions.

In fact, as a premier packager for Fedora + derivatives including but not 
limited to Red Hat Enterprise Linux and CentOS, and add-on repositories such 
as Extra Packages for Enterprise Linux as well as RPM Fusion, I can tell you I 
would hate to have to work with and around OBS;

The OBS builds based on what SUSE thinks is an upstream version of RPM, while 
it's not. Undoubtedly, the build tools they use for APT-based distributions 
are much closer to what is in the actual distributions. Either way, in 
relation to my domain, RPM-based systems, as such, it is simply fundamentally 
flawed. The results stretch from allowed packaging foo that would never be 
accepted by any actual distribution, to retraceable steps during builds 
resulting in non-reproducible build products nonetheless. If I were to draw an 
analogy it would have to be; fixing your car with only a hammer

If you want to build native packages for a distribution, I very, very strongly 
recommend to use the methods of such distribution (whether in your own 
repositories or not), stick to their specific packaging guidelines, and use 
their packaging efforts as well as your own to move both forward. For APT-
based systems, this means git/svn/cvs/hg-buildpackage w/ pbuilder/cowbuilder 
(if not distributed), for RPM-based distributions this means dist-git and 

Kind regards,

Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at
t: +316 42 801 403

pgp: 9342 BF08

More information about the Info-cyrus mailing list