Development

Building RPMs using Mock's SCM integration

Building a single RPM once is a relatively simple task, which is accomplished by tweaking the spec file and running it through rpmbuild on the local system. However, when more than one or two people are involved and several RPMs for several distributions are being maintained over a long period of time, reproducibility and change tracking become essential. A new feature in Mock, which builds RPMs from source, will make it easier for developers and projects to handle this task.

Koji offers a centralized build system for distributions like Fedora with hundreds of developers and a dedicated infrastructure team. Unfortunately, setting up Koji is not the most straightforward task. Few will enjoy investigating miscommunications between Koji components when building an RPM fails, for example, or how to adjust repository settings in a database instead of a simple yum-format configuration file. In some cases Koji's centralized nature is also a limitation because using it might require setting up a VPN connection to an organization's network.

Mock is the tool used by Koji to create chroots and build RPMs in them. Up until recently, Mock, which runs on the local system, has required source RPMs when used directly. This is not really optimal since building source RPMs requires extra steps. It is also worth remembering that the RPM version of RHEL 4/5 is unable to handle source RPMs created with the default options on RHEL 6 or recent Fedoras due to RPM package format changes.

The recent release of Mock 1.1.10 introduces an interesting feature to seamlessly integrate RPM building with CVS/Git/SVN workflow. After initial Mock installation and configuration (i.e., just adding user(s) to the mock group) all that's needed is to define the default source code management (SCM) method and its checkout command in Mock's site-defaults.cfg main configuration file. After that Mock can build RPMs directly from the SCM repository provided that a spec file suitable for rpmbuild is found inside the repository. Mock first builds the source RPM in a selected chroot and then the binary RPMs from it in the same chroot.

Building an RPM directly from the default SCM in a Mock chroot is as easy as:

    mock -r fedora-14-i386 --scm-enable --scm-option package=testpkg -v

In this example first the target (-r fedora-14-i386) is specified, then the SCM integration is enabled (--scm-enable) and the actual package to be build is set (--scm-option package=testpkg). Also, a modest level of tracing is enabled (-v). Otherwise defaults from the Mock configuration file are used, including the default SCM method (one of CVS/Git/SVN) and the location of the SCM repository.

This SCM integration allows two possibilities for setting up repositories: the repository may contain all the source and configuration files needed for a package (the tar ball needed during the build process will be generated on-the-fly) or the repository may contain only the spec file, possible patches, and local configuration files, then the tar package can be fetched from an NFS mounted directory for example. Then Mock running on a 64-bit RHEL 6 system, for instance, can be used to build RPMs from an SCM for 32/64-bit RHEL 4/5/6, Fedoras, and other RPM-based distributions. In many cases a spec file doesn't need any extra directives for different distributions but, if needed, distribution or version specific if/else definitions can be used to allow using the same spec file for all targets. As long as the package repositories for targets are publicly available, no access to the organization's network is needed when building.

Using Mock's SCM integration capabilities allow organizations' package maintainers to combine the easiness of plain rpmbuild with build reproducibility and change tracking offered by Mock and SCMs, but without the overhead of Koji. Trivial configuration, being able to trace the build process locally if needed, and using the build system while roaming are also noteworthy features. In the future, integrating all this into higher level tools like Emacs or Eclipse would open interesting possibilities for developers: generating RPMs for several targeted distributions directly from an SCM in a reproducible manner with a single click on the GUI.

Comments (none posted)

Brief items

Qtractor 0.4.9

Qtractor is a MIDI sequencer; the 0.4.9 release is now out. New features include audio latency compensation, "MIDI scale-quantize and snap-to-scale tools," "MIDI controller invert value and connects access," and "Audio peak/waveform generation pipeline."

Full Story (comments: none)

Synfig Studio 0.63.0

Version 0.63.0 of the Synfig animation tool is out. New features include better outline control, improved bline editing, a port to cairo, canvas guides, and more. (Thanks to Paul Wise).

Comments (none posted)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (June 7)
• PostgreSQL Weely News (June 5)
• Python-URL! (June 7)
• Tahoe-LAFS Weekly Newsletter (June 7)

Comments (none posted)

Aslett: The trend towards permissive licensing

Matthew Aslett argues that the popularity of copyleft licenses is in decline. "This last chart illustrates something significant about the previous dominance of strong copyleft licenses: that it was achieved and maintained to a significant degree due to the vendor-led open source projects, rather than community-led projects. One of the main findings of our Control and Community report was the ongoing shift away from projects controlled by a single vendor and back toward community and collaboration. While some might expect that to mean increased adoption of strong copyleft licenses - given that they are associated with collaborative development projects such as GNU and the Linux kernel - the charts above indicate a shift towards non copyleft."

Comments (18 posted)

Meeks: LibreOffice progress to 3.4.0

Michael Meeks digs in to the changes that went into LibreOffice 3.4, including better translation support, merging changes from OpenOffice.org (part of which was a "multi-million-line" OO.o cleanup patch), adding more build bots, and more. One major area of work was in doing some cleanup to reduce the size of LibreOffice: "First - ridding ourself of sillies - there is lots of good work in this area, eg. big cleanups of dead, and unreachable code, dropping export support from our (deprecated for a decade) binary filters and more. I'd like to highlight one invisible area: icons. Lots of volunteers worked on this, at least: Joseph Powers, Ace Dent, Joachim Tremouroux and Matus Kukan. The problem is that previously OO.o had simply tons of duplication, of icons everywhere: it had around one hundred and fifty (duplicate) 'missing icon' icons as an example. It also duplicated each icon for a 'high contrast' version in each theme (in place of a simple, separate high contrast icon theme), and it also propagated this effective bool highcontrast all across the code bloating things. All of that nonsense is now gone, and we have a great framework for handling eg. low-contrast disabilities consistently."

Comments (14 posted)

Linux Photo Tools (The H)

Here's a lengthy survey of photo processing tools (some proprietary) on The H. "If you are prepared to deal with multiple user interfaces and software handling concepts, you will be able to produce professional looking results by using clever combinations of appropriate tools. This is a tried and trusted approach for many Linux users, who are familiar with using collections of individual tools that each perform one specific task particularly well. The choice of efficient photo workflow tools for Linux is not as wide as it is for Windows, but there is nevertheless a good selection of powerful programs available for importing, viewing and geotagging your images, as well as for performing a multitude of other tasks."

Comments (12 posted)

Walter: The Go Programming Language, or: Why all C-like languages except one suck

Jörg Walter has written a detailed and positive review of the Go programming language. "And as a final note, I have seen a fair amount of criticism of Go on the internet, which I cannot ignore, so here it goes: Most of these people didn't actually look at it. Go is different, even though it still looks kinda-C. It isn't. It's not C++, nor Objective C, and it doesn't try to be! So stop saying 'Who needs Go when we have C++/Objective C?' already. Check out how Go tries to solve the same problems in a radically different way."

Comments (110 posted)

Page editor: Jonathan Corbet
Next page: Announcements>>