What about starting to use project-builder for native packages?
ml at radoeka.nl
Mon Apr 19 20:29:09 CEST 2010
Op maandag 19 april 2010 08:04:31 schreef Gunnar Wrobel:
> >> 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.
Collaboration is one of main drivers of the build service...
> 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.
A project branch is a set of deltas (diffs) to the original project. If you
don't do anything and add the same repositories then you will get exactly the
same resulting packages. Any tarball can be patched, any file from the
original project can be deleted or replaced, and new files can be added. When
the upstream project changes, it triggers a rebuild in the branches using
So you could have your sources in one project with no control files or
repositories and a branch for each distro that adds the necessary spec and
control files. Each branch would add distro repositories so the composite of
sources from the 'root' and spec files are built vs one or more distribution
> 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.
No cross-distribution spec file template system is imposed by the build
service, and you are free to use one.
The 'conventional workflow' for cross-distribution specfiles is have separate,
manually maintained setups for rpm and deb systems using conditionals. But
since specfiles are just files like anything else, you can use something else
The prjconf mechanism can be used to define variables (and rpm macros, not
sure if these are available to non-rpm builds) across all packages in a
project and its branches.
Another way to share settings between packages is to put them in custom rpm
macros, in a package, that is a build requirement of other packages.
Some projects in the OBS use simple ad-hoc templating they have developed
themselves that is specific to each package, eg a .spec.in file is processed
on checkin to substitute variables from some template control using perl or
sed scripts contained in the package to create a usable specfile.
Others have developed domain-specific templating systems such as kde-obs-
generator (http://en.opensuse.org/KDE/Build_Service/Cross-distro) that use an
input template and the source's buildsystem to generate cross-distribution
spec files for any project in that domain.
I hope that also explains a bit the possibilities / limitations of the build
More information about the users