What about starting to use project-builder for native packages?
ml at radoeka.nl
Sat Apr 17 21:42:25 CEST 2010
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)
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
> 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
More information about the users