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

[Richard Bos]

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

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


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

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

-- 
Richard