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
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
