Bundling – what’s changed, and what’s the big deal?
I’ve talked about bundling and unbundling in the previous 5tFTW, and a month ago as well, and we’ve been debating the issues on the Fedora devel list, in a gigantic thread with hundreds of replies.
The quick overview is that “bundling” is a software development practice where, when the program you are writing requires some support software, referred to as a “library”, you just copy that library right into your program. The alternative is to use a shared version common to all of Fedora, but there are various reasons (good and bad, and simple and complex) that developers sometimes don’t.
Fedora has long had a fairly strict rule against including software with bundled parts in the distribution. Packagers wanting to include software were required to make sure that these parts were separated out, either to use existing shared versions, or if those didn’t exist independently in Fedora already, to create a new package for each one. In some cases, the Fedora Packaging Committee — FPC — would grant exceptions, but generally in limited situations.
There are definite benefits from unbundling, including better use of disk and memory, and potentially less work when a security incident is found. But in practice, I think this was an example of the perfect as the enemy of the good — that is, by having this bar raised really high, we were actually making things worse in practice.
Last week, FESCo, the Fedora Engineering Steering Committee, passed a high level policy which relaxes the rules very significantly. The new policy says software which can use system libraries must do so, but unbundling is no longer a hard requirement. Packagers need to contact the upstream and document that, and (crucially for security) all bundled libraries must be labeled in the package itself.
I think this is a big step forward for Fedora, which will make it a lot easier to get a lot of important, modern software to Fedora users, and which will make packaging feel a lot less discouraging. It’s important for Fedora to recognize that developers aren’t just all insane, lazy, or both — although not everyone will agree with the conclusion, there are at least rational arguments for the bundling approach to software, and it’s better for us to be at least in dialog rather than flat-out hostile. But I also want to stress two other things.
First, FESCo’s intention is not to put down some metaphorical boot. This is meant to be a starting point for building up new policies, and is very open to clarifications and refinements where needed. See the ticket clarifications/improvements for new bundling policy if you’re interested in the sausage being made. I hope to see FESCo and the FPC working together to come up with new guidelines that reflect the more open approach while also covering some of the areas left unclear by last week’s decision.
Second, this doesn’t mean that Fedora has given up on package quality, and doesn’t mean that we enshrine bundling as the best approach. There’s a loose proposal on the Fedora devel list for an “Unbundling SIG”, consisting of people who are really passionate about this problem and with authority to work with packagers on unbundling where it makes sense and has high impact.
We also need better tooling. Right now, we rely on individual, initial manual package review to identify bundled libraries. It would be much better if we’d scan all of our software, including new versions. There’s a lot of code in Fedora, but fundamentally, this kind of identification is something computers can handle well — we just don’t have the tooling to do so currently. I think it’s very safe to say that Fedora with such tooling and the new policy will be a lot more secure than Fedora without it and the old policy.
So, in short, unbundling is dead, but long live unbundling… if enough people are really interested in working on it.
Openings for Outreachy Interns
Outreachy is an internship program which helps people from groups underrepresented in free and open source software get involved. This year, we’re sponsoring two openings to work on Fedora, one funded by Red Hat platform engineering, and one from the Fedora community budget. If you’re interested or know someone who would be awesome for this, take a look at our Outreachy 2015 wiki page.
Fedora Council Budget Discussion
The Fedora Council defaults to open discussion, but occasionally we do private calls when matters are sensitive. Sometimes, it seems like nothing in the world is more sensitive than money, and on Monday, we had a private call with Ruth Suehle, who works for Red Hat’s Open Source and Standards group and is responsible for Fedora’s community budget, which funds the Flock and FUDCon conferences, Fedora Activity Days, and all of the activities of the Fedora Ambassadors. (Ruth, of course, is also a Fedora contributor, with previous work in Fedora Marketing and a huge force behind the overall success of Flock.)
I posted notes from that call to the Fedora Council Discuss list. If you’re part of the Fedora Ambassadors, or would like to be, I definitely recommend you join the discussion. There are a lot of areas where we could be doing better. There’s no shortage of areas where we could make a difference by spending some money, but we need to collectively work harder at measuring the impact of what we do, so that we can effectively request the resources to do even more.
Fedora 23 Status
Not to be forgotten in all the above, the Fedora 23 release is just around the corner. We entered the “final freeze” yesterday, which means that no changes can be made without special exception, and release engineering will switch from making test candidates to release candidates, which are builds of all of the various Fedora artifacts (install media for Fedora Server, live CDs for Fedora Workstation, qcow2 and AMI images for Fedora Cloud, all the spins and ARM images, and everything else). Once a release candidate passes release validation by the Quality Assurance team, we’ll call it “gold” and ship it to you, with a target date of October 27th, less than two weeks away and just in time for Halloween.
DNF in the buildroot
And, ending on a technical note for packagers (and the curious):
You probably know by now that the DNF package manager has replaced Yum in Fedora — at least on installed Fedora systems. The build environment where we produce the RPM packages which comprise those systems, though, still used Yum, up until this week. DNF is mostly a drop-in replacement for Yum, but it uses and entirely different approach to depsolving – that is, figuring out which packages a given package needs in place to actually work or build. So, making this switch is kind of a big deal, because it could reveal packaging mistakes which were hidden by the way Yum happened to order things – or of course real DNF bugs as well.
As of this week, Release Engineering switched Rawhide (Fedora constantly-moving development branch) to use DNF. There were a few glitches as not all systems had been updated to the latest version of DNF, but that’s all smoothed out now. If you see any new problems, post on the development list about it. (Note that F23, F22, and EPEL builds will continue to use Yum.)