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

Stephan Holl stephan.holl at intevation.de
Sat Oct 16 14:33:03 CEST 2010


Hello BH, Bernhard,

Bernhard Herzog <bh at intevation.de>, [20101015 - 22:47:07]

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

I was initially asking this question in order to get more involved in
treepkg. Currently we are using the opensuse build service for building
RPM-based packages which 'just works'.
There are some good reason not use this service so I was investigating
[1] a little bit closer. AFAIK there ist some more functionality in OSB
than in treepkg and I am interested if it is worth extending treepkg to
get in concurrency to OSB.

Actually I am not in the position to get the costs of packaging from my
clients as the expect them to be available.

Best

	Stephan

-- 
Stephan Holl <stephan.holl at intevation.de> | Tel.: +49 (0)541-33 508 3663
Intevation GmbH, Neuer Graben 17, 49074 OS  |  AG Osnabrück - HR B 18998
Geschäftsführer:  Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/treepkg-devel/attachments/20101016/ba31882e/signature.pgp


More information about the Treepkg-devel mailing list