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.
Cheers,
Gunnar
>
>
> --
> 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