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

Gunnar Wrobel wrobel at pardus.de
Mon Apr 19 08:04:31 CEST 2010

Hi Richard,

Quoting Richard Bos <ml at radoeka.nl>:

> 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...

I don't know if getting the Kolab server packages fully integrated  
into downstream should have a large focus. I think we are fine as long  
as we have working packages for the different distros. Of course full  
downstream integration is always nice but that would also limit us in  
our flexibility. On OpenPKG we were free to modify any package to the  
extend we needed it in order to get the required functionality. And  
that sometimes meant adding patches we knew were hacks. And I don't  
think we want to loose this option by abiding to all downstream  
quality criteria.

>> In general I think that packagers should only build packages for distros
>>  that  they are familiar with.

I second that. And I agree that having merged spec files that try to  
cope for all distros will be difficult. Initially I thought I didn't  
care very much as all I would like to see are working packages on the  
different distros.

However one of the main reasons why we are considering a tool that  
allows to build packages for several distros at the same time is that  
we want to have a better information exchange between the developers  
on the different distros.

And ideally that means that we have a mechanism that allows us to  
extract only the parts of the package definition that change across  
the different distributions while allowing the packagers to merge this  
core information with their specific spec file templates that fits the  
needs of their distribution.

> Cross-distribution Specfiles are the smallest part of what the OBS does.

I think this is one of the core tasks that we have however.

> 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.

Can you elaborate on how that works? What you describe does of course  
match our situation. We have several experienced packagers working on  
different distributions. So we'd definitely have to go into that  
"branching" direction.

Does this also work template based? What I wouldn't like to do is have  
one core spec file for OpenPKG for example and the other distros would  
need to derive/branch from that in the sense of branching how it is  
done in a revision control system. Trying to merge commits that were  
specific to the OpenPKG spec into the spec file of another distro  
would mean that you need to know the mechanics of the OpenPKG spec  
file definition.

I don't see an alternative to "template based" here. It should be  
comparable to what I did with the PEAR packages in Kolab server CVS  
HEAD a while ago. In fact if we'd use neither of the currently  
discussed build services then I'd still hope we could simply use this  
simple Makefile based approach.

> 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.

Nope, this is something project-builder avoids by using templates.

> 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

To me it wouldn't matter as long as we have a possible exit in case  
the OpenSUSE build service dies, is unreliable or whatever. And that  
seems to be given as you detailed in your other mail.



> --
> Richard
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users

______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/users/attachments/20100419/b2450682/attachment.sig>

More information about the users mailing list