What about starting to use project-builder for native packages?

[Richard Bos]

Op donderdag 15 april 2010 11:36:18 schreef Christoph Wickert:
> > Short reply on Thomas' remark, I'll reply on Gunnar's email later:
> > - the packages build on the openSUSE build server are, native Fedora,
> > Mandriva, Ubuntu, Debian packages!   They are -->not<-- openSUSE
> > specific.
> 
> FWIW they are kind of specific. Please let me explain:
> Each distribution has different packaging guidelines, different macros 
> different package names and all that stuff. Developers usually focus on
>  this  or that distribution. I for example focus on Fedora/CentOS and
>  Debian/Ubuntu but hardly don't know anything about OpenSUSE or Mandriva
>  and nearly nothing about Gentoo...
> 
> In general I think that packagers should only build packages for distros
>  that  they are familiar with.

Cross-distribution Specfiles are the smallest part of what the OBS does.  If 
you are a single packager they make sense, and until now the efforts to 
promote the OBS outside openSUSE have targetted this group.  They are more 
complex, but less work to maintain and keep in sync than a suit of native 
specfiles for different distro versions.  If OTOH you already have a team of 
distribution specialist packagers then they can continue to use native  
specfiles in branched projects that share a common set of tarballs and  
patches.  OBS saves the overhead of distributing updated sources to all and 
publishing built packages to repos.


> > Takes this repository as an example:
> > http://download.opensuse.org/repositories/home:/rbos:/ib/
> 
> I looked at your packages and none of the specs for the Fedora 
> packages would really be acceptable for inclusion in Fedora, even though
>  the  guidelines for Fedora and OpenSUSE are pretty similar (because
>  OpenSUSE took over large parts of Fedora's guidelines, including the typos
>  ;)).  Please don't take this as personal criticism, I'm just stating facts.
> 
> > One spec file (for rpm based distributions) results in packages for many
> > different distributions and architectures.  This is done by loading an
> > image with e.g. Mandriva and perform the build the build of the spec file
> > in that image.  Really wonderful
> 
> If you try to honor all the differences between the distributions, you end
>  up  with a spec full of conditionals. So what happens is that the spec
>  gets hard to maintain, but on the other hand the value it adds - one spec
>  to rule them all - is pretty small.

This is a given and is valid for any package build system, that results in 
packages for different distributions.  

The build service can be used in many different ways.  One spec file for all, 
or if you want more control: branch the project (even against a remote build 
service).  It's all possible!  BTW if Kolab wants to get kolab into 
distributions' own repositories and maintain the specfiles themselves, they 
need native specfiles. 

A possible project hierarchy for native spec files could be:
Kolab: (containing only sources and patches)
      /openSUSE:/11.2
                /11.3
      /debian:/hardy
              /Unbuntu10.4
      /fedora:/12
              /Centos
which all add the spec/.dsc/control files.  If a branch cannot accept a 
version update from the main branch, it can copy the old tarball in and 
continue to build using that.


> For those who never looked at the OpenSUSE Build Service, please take a
>  look  at
>  http://en.opensuse.org/Build_Service/cross_distribution_package_how_to
> 
> Even worse than a cluttered spec: A lot of the macros are OSB specific, so
>  the  resulting SRPMs cannot be rebuild on the distributions they were
>  built for - they can only be built inside the OSB.

If customers need to rebuild locally they can always use 'osc build' to build 
using cross-distribution specfiles.

If all you are interested in is distributing binary packages to users, the 
resulting RPMs from cross-distro specfiles, given thorough packaging work, are 
indistinguishable from natively built RPMs.


> I haven't looked at project-builder yet, but I think we should take it
> into account because for me OSB is not an option.

Because the OBS (openSUSE Build Service) is hosted by openSUSE?  I sincerely 
hope, that it is not for this reason!  If it is, Kolab can host the build 
service at e.g. http://build.kolab.org or why not at http://build.kolabsys.com 
(or even on both locations) The tools are open source and freely downloadable 
from http://download.opensuse.org/repositories/openSUSE:/Tools and
http://gitorious.org/opensuse/build-service


-- 
Richard