OpenSuSE Buildsystem

[Andreas Thienemann]

On Wed, 17 Dec 2008, Number Cruncher wrote:

> As a developer for a small ISV selling engineering analysis software 
> (www.cambridgeflowsolutions.com), I'm responsible for packaging our 
> software into RPMs for clean installation anywhere from e.g. RHL7.3, 
> SUSE 9, to RHEL5, Fedora 10, and SLES10.

RHL7.3? Congratulations, I managed to move _all_ my customers away from 
that. Even though it was _the_ rock stable enterprise operating system. 
5 years uptime and counting on some of these boxes. :)

> This stuff really matters to me - I've spent many days tearing my hair 
> out with build-related issues. At present, we've a single spec file with 
> many %if clauses to handle all the different package naming conventions 
> on SUSE/RedHat over time. There are 60 lines just to select the right 
> X11 BuildRequires.

I fear however, that buildsystem synchronisation is not really going to 
help you very much. What you're looking for is more something like United 
Linux and we all know how that fared.


> In theory, this single source RPM should then build on either 
> buildsystem. We can't release our source to a public buildsystem, so I 
> run mock 0.7.2 in-house with some custom buildgroups and buildsys-macros 
> which I have to maintain to populate the initial chroot.

Doesn't sound like a bad idea. Many companies are running their in house 
builders on mock.
 
> Trouble is the latest mock (0.9.13) won't build my SUSE-related RPMs 
> (hangs on some file descriptor during chroot construction). And the SUSE 
> buildsystem isn't as easy to install locally as mock, so I can't use 
> that without spending many more days....

Bug. check the debug output.

> Every time a new release arrives from a major Linux distributor, I have 
> to spend hours trying to cajole my old mock builder to work with it.

Personally, I find these %if %endif-ed specs for a bunch of distros 
horrible to read.
including Buildreqs etc. from other files might make that easier to read, 
but it's a hackish solution nevertheless.

regards,
 andreas