Repos [Was: competition]
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
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
Koji.
Kind regards,
--
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com
pgp: 9342 BF08
More information about the Info-cyrus
mailing list