OpenSuSE Buildsystem

Number Cruncher number.cruncher at ntlworld.com
Wed Dec 17 12:57:41 UTC 2008


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.

We choose RPM so that it integrates seamlessly into the client's OS 
(including MIME types and icons), and can be upgraded/uninstalled 
cleanly. It depresses me that most ISVs still use shell-based tar 
archive installation and endless LD_LIBRARY_PATH manipulation, simply 
because building cross-distribution RPMs is so hard.

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.

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.

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

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.

> 
> I see great benefit to everyone by having that problem solved at the rpm.org 
> level.  it will make it much easier to pickup packages and fixes cross distro.  
> that is not a bad thing. especially for ISV's and upstreams supporting all 
> distros  they only need to do the work once and build everywhere.
> 
Some things can't be solved at rpm.org: buildrequires package names, how 
to distinguish Fedora 4 from RHEL5.

> Working directly with them to fix issues for there buildsystem however I feel 
> causes some conflicts.  namely it legitimises the use of there buildsystem for 
> building fedora/RHEL packages.  I  know people use it and will continue to do 
> so.  but I would ask why?  is there some service that fedora could provide and 
> is not?  is it because you can be lazy and sloppy in the packaging and it lets 
> you?  is it just being able to do it in a single place? 

It shouldn't matter *how* you go from .src.rpm to the binaries. Provided 
your package is clear on its dependencies (with clauses for either 
platform), who cares if you use SUSE's builder or RedHat's?

 From an ISV standpoint: I wish to go from a source RPM to a binary one 
for approximately 20 Linux distributions and architectures. I don't mind 
  coding "if RHEL == 5 use tcp_wrappers, if fedora >=7 use 
tcp_wrappers_devel, if suse use tcpd_devel". Just provide me with a 
single tool I can run locally which automatically pulls in the 
appropriate BuildRequires and generates the binaries. How you distribute 
the binaries and manage updates, etc. is a separate issue.

I know this is possible, because I'm currently doing it. But with an 
outdated version of mock that needs a reboot if interrupted and some 
buildsys-macros which I think could/should be easily provided by the 
Linux vendors.

As for why: mutual benefit. I've seen Windows make huge in-roads in the 
Engineering sector because of the ease of software admin. No one likes 
shell-based installs and custom environment variables. RPMs solve this 
with one-click install/uninstall.

Make it easier for ISVs to create RPMs and you make it easier for 
companies to choose Linux. Make it harder and ISVs will either reduce 
the number of supported Linux vendors, or plump for the more tightly 
defined world of Windows.

Simon.

> 
> We do need to get out of the business of running two buildsystems. we really 
> do need to be able to build EPEL in koji.  I have scheduled a koji hackfest 
> for fudcon.  so if your there and interested then come help.  there is always 
> #koji on freenode for discussion on koji,  so if you cant make it in person 
> you can be there virtually :)
> 
> Dennis
> 
> --
> Fedora-buildsys-list mailing list
> Fedora-buildsys-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list




More information about the Fedora-buildsys-list mailing list