[Treepkg-devel] Fwd: RPM-Buildes possible?

[Bernhard Herzog]

On 13.10.2010, Bernhard Reiter wrote:
> Am Mittwoch, 13. Oktober 2010 14:58:35 schrieb Sascha L. Teichmann:
> > is it possible to build RPM packages (Suse-specific) with treepkg?
>
> I would expect the interesting parts of treepackager to be independent
> from the build commands it would need to execute.

To an extent.  Some debianisms are spread through the code because so far only 
debian packages had to be supported.  It shouldn't be difficult to fix that, 
though.  Some of the things that would need to be done:


- We need an equivalent of pbuilder

This basically means a tool that takes a source package and builds the
binary packages from it.  The build needs to be isolated from the host
system with at least something like a chroot environment and the tool
should preferably be able to automatically install build dependencies.
It's OK if the tool only works on OpenSuse/SLES/etc. since we can run
the treepkg itself on that system.

It might even be possible to build something with pbuilder on Debian by
running "pbuilder execute" with suitable shell scripts.  This might
require more than a chroot, but e.g. qemubuilder could perhaps be used
for this.


- The SourcePackager class has to be split

The SourcePackager class does too much and should be split up into at
least two parts.  This is a good idea anyway, even without RPM support.

SourcePackager exports the sources from the version control system,
creates a tarball from that and finally a source package from the
tarball and some additional files (debian subdirectory possibly taken
from another repository).  This should be split into at least these
classes:

  SourceArchiver

    Exports the sources and builds a tarball from that.  Basically the
    class does what the upstream maintainers would do to make a tarball
    release.  This often includes updating version numbers in the
    sources somewhere and perhaps running automake and/or autoconf.

    This part is independent of the target distribution.  It often does
    depend on details of the software being packaged, though.
    E.g. which files need to be modified, how to automatically determine
    a good version number for the release, whether autoconf needs be
    run, etc.

  SourcePackager

    Takes a source tarball creates a source package from it.  This
    process will usually need some more files as input, e.g. the debian/
    subdirectory for Debian packages or the spec-file for RPMs.

    The tarball will usually be produced by a SourceArchiver but it
    could also be created in some other way.  The SourcePackger
    shouldn't care about that.

    Obviously there would be different SourcePackager class for the
    different package systems, there would have to be a
    DebianSourcePackager and an RPMSourcePackager.  If they do have code
    in common, they should derive from the same base class.

    The SourcePackager should be relatively independent of the software
    being packaged, though.


- RPM-Based BinaryPackager

The BinaryPackager takes a source package and builds binary packages
from it.  The current class is quite debian specific.  As with the new
SourcePackager class, there would have to be a DebianBinaryPackager and
an RPMBinaryPackager with perhaps a shared base class.

The actual building of the binaries is abstracted in the Builder
classes. There would have to be a Builder class for RPM bases systems,
obviously, using the pbuilder equivalent mentioned above.

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner