Comments on: Fedora/RPM packaging

By: Adam

Adam — Tue, 09 Sep 2008 16:25:13 +0000

This reminds me, I’ve got to install an OS with a smaller footprint on my old laptop. The thing takes about 234,734,698 hours to boot WinXP. I’ve used Fedora before and was quite happy with it. Have any other suggestions?

By: Rahul Sundaram

Rahul Sundaram — Tue, 19 Aug 2008 15:48:00 +0000

“My main annoyance with RPM is that in case of errors you usually need to rebuild from scratch. There’s no easy way to “continue” a build after fixing the problem.”

rpmbuild has a –short-circuit switch.

“And, of course, yum is a steaming pile of shit ;-)”

Of course, it isn’t ;-) or atleast your comment wasn’t specific enough.

By: Bernie Innocenti

Bernie Innocenti — Sat, 16 Aug 2008 06:57:04 +0000

Re “2. No build customisation”, one could use conditionals such as “%if 0%{?olpc}”, which expands to “01″ when olpc is defined to 1, and to 0 when it’s undefined. See the xorg-x11-server.spec in OLPC-2 for an example.

Re “3. Convolution/confusion of build tools”, koji can build srpms: just say “koji build –scratch mypackage.src.rpm”. The problem is that it doesn’t let you build multiple packages dependent on each other, so it cannot be used to work on, say, a new version of X11.

My main annoyance with RPM is that in case of errors you usually need to rebuild from scratch. There’s no easy way to “continue” a build after fixing the problem.

And, of course, yum is a steaming pile of shit ;-)

By: Rahul Sundaram

Rahul Sundaram — Tue, 22 Jul 2008 18:48:51 +0000

Newer versions of RPM can detect more build requirements at runtime but it is still provided explicitly for compatibility reasons at times. Yes, build customization can be a problem but the solution atleast in this case is to work with Fedora to split up packages more granularly. In fedora-devel list, some of the OLPC folks pointed a few issues related to this which are being resolved in the development branch of Fedora (Rawhide).

“. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think”

I am not sure where you get this impression. Every single package is build using Koji (http://koji.fedoraproject.org) which itself uses mock directly against the spec files. You do not need rpmbuild at all. Maybe OLPC is doing something different that I am not aware of. Feel free to login to #fedora-devel and ask if you have doubts. Good to hear a different perspective nevertheless.

By: Daniel Drake

Daniel Drake — Tue, 22 Jul 2008 16:35:01 +0000

Yes, gnome-python2 is already split up into subpackages in Fedora, but not well enough at the moment. https://bugzilla.redhat.com/show_bug.cgi?id=456122

By: Mart Raudsepp

Mart Raudsepp — Tue, 22 Jul 2008 15:53:08 +0000

Regarding the GNOME python bindings (gnome-python, gnome-python-desktop and gnome-python-extras tarballs), one can just split it out into multiple packages. I figured binary distributions are doing it long ago, as it’s easier for them, but I guess not then…
For Gentoo ford_prefect will be committing the split up packages to portage soon as his first bigger thing as an official Gentoo developer :) So we will have packages for every binding separately, so you won’t need to pull in the whole stack through libgnome bindings just because you just want to “import gconf”. The old package will be converted to a meta package that pulls in all the separate ones, so that the files installed by the monolith will be the same as when installed by the meta package, for easier migration by packages - they can gradually stop rdepending on the big thing at their leisure, considering their time and concerning keyword visibility matching.

As for runtime dependencies, there are at least scripts around for Gentoo as well that can list you what packages are needed at runtime as figured out by it (of course doesn’t find dlopened stuff, probably just like Fedora, etc), so it’s easier to get a starting point to put in the ebuild. That said, in the GNOME world (and I imagine in most places), we just go with what configure.in checks and they are often listed all at once in variables in the same place and later those variables are used as necessary (sometimes inside various conditionals, like if a feature was enabled or not) , so that it’s easy to see minimal version dependency changes for example.
For instance in gtkhtml’s configure.in (just happened to be unpacked here):

# Required Package Versions
m4_define([gtk_minimum_version], [2.10.0])
m4_define([gail_minimum_version], [1.1.0])
m4_define([gnome_icon_theme_minimum_version], [1.2.0])
m4_define([libbonoboui_minimum_version], [2.2.4])
m4_define([libglade_minimum_version], [2.0.0])
m4_define([libgnomeui_minimum_version], [2.0.0])

That said, these scripts and such tools should get collected better and perhaps integrated into a smaller number of tools