linux.conf.au 2010: Day 1 (afternoon)

Sometimes, when I have a conflict like this, I try to attend the talk whose material is less familiar to me (in this case, probably the SVG/Flash one). However, since the talks are being recorded and made available on the Internet, this changes the dynamic a bit. I don’t have to miss out on watching anything, as I can download it later. So, it makes more sense for me to go where I can best participate, taking advantage of my presence at the conference.

Distro summit: Package management

So, I chose to attend the package management talk, as I might have something to contribute. It was about how to harmonize general distribution packaging mechanisms (dpkg, RPM, etc.) with special-purpose ones like those used by Ruby (gems), Lua (rocks), Perl (CPAN modules) and so on. The solution described employed a set of wrapper scripts to provide a standard API to these systems, so that they could be used by the distribution package manager to resolve dependencies.

Due up next was Scott James Remnant’s talk on booting faster, but due to travel difficulties, he hadn’t arrived yet. Instead, we had a free-form discussion on various other challenges in the area of package management.

I took the opportunity to put forward an idea I had been thinking about for some time, which is that we may need to move beyond a “one size fits all” or “everything is a package” approach to package management. Modern package management systems are very capable, and solve a range of difficult problems with a high degree of reliability. The cost of all of this functionality is complexity: making packages is difficult. The system can be made to work for a wide range of software, but the simple case is often not very simple.

I also made the point that there are non-technical challenges as well: it is difficult for developers and ISVs to understand the ecosystem of distributions, and even more difficult to succeed in making their software available in “the right way” to Linux users. The obstacles range from procedural to cultural, and if we only approach this as a technical problem, we risk adding more complexity and making the situation worse.

The opportunity to have this kind of participatory discussion really validated my decision about how to choose which talk to attend.

Liz Henry: Code of our Own

Back in the Haecksen/LinuxChix miniconf, Liz Henry presented an action plan
for increasing the involvement of women in open source, with many well-considered “dos” and “don’ts” based on observations of what has and has not worked for open source communities.

It was the first opportunity I’ve had to attend a free software conference session which went beyond the typical “yes, this is important” and “yes, there really is a problem here” content which is unfortunately as necessary as it is commonplace.

I won’t attempt to summarize it here, but I can definitely recommend Liz’ presentation to anyone who is looking for concrete, actionable methods to promote gender diversity in their technical communities.

Lucas Nussbaum: The Relationship between Debian and Ubuntu

Historically, in Lucas’ assessment, many Debian developers have been unhappy with Ubuntu, feeling that it had “stolen” from Debian, and was not “giving back”. He said that bad experiences with certain people associated with Canonical and Ubuntu reflected on the project as a whole.

However, he says, things have improved considerably, and today, most Debian developers see some good points in Ubuntu: it brings new users to free software and Debian technology, it provides a system which “just works” for their (less technical) friends and family, and brings new developers to the Debian community.

There are still some obstacles, though. Lucas says that many bugfix patches in Ubuntu are just workarounds, and so are not very helpful to Debian. He gave the example of a patch which disabled the test suite for a package because of a failure, rather than fixing the failure.

He felt that Canonical offered few “free gifts” to Debian, citing as the only example the website banner on ubuntu.com which was displayed for Debian’s 15th anniversary. I felt this was a bit unfair, as Canonical has done more than this over the years, including sponsoring DebConf every year since Canonical was founded.

It occurred to me that the distinctions between Canonical and Ubuntu are still not clear, even within the core free software community. For example, the “main” package repository for Ubuntu is often seen to be associated exclusively with Canonical, while “universe” is the opposite. In reality, Canonical works on whatever is most important to the company, and volunteers do the same. These interests often overlap, particularly in “main” (where the most essential and popular components are).

Lucas speculated that more mission-critical servers run Debian pre-releases (especially testing) than Ubuntu pre-releases. It would be interesting to test this, as it’s rare to get sufficient real-world testing for server software prior to an Ubuntu release.

Lucas presented a wishlist for Ubuntu:

more technical discussions between Ubuntu and Debian (particularly on the ubuntu-develdebian-devel mailing list

easier access to Launchpad data

Launchpad PPAs for Debian

The prominence of Launchpad in these discussions spawned a number of tangential discussions about Launchpad, which were eventually deferred to tomorrow’s Launchpad mini-conf. One audience member asked whether Debian would ever adopt Launchpad. The answer from Lucas and Martin Krafft was that it would definitely not adopt the Canonical instance, but that a separate, interoperating instance might eventually be palatable.

I made the point that there is no single Debian/Ubuntu “relationship”, but a large number of distinct relationships between individuals and smaller groups. Instead of focusing on large-scale questions like infrastructure, I think there would be more mileage in working to build relationships between people around their common work.

6 Responses

Re: “we may need to move beyond a “one size fits all” or “everything is a package” approach to package management. ”

I don’t know the tech details… but I think you are on to something. Why should “One size fit all” at the first place? We have different security concerns (Kernel vs HTML or java applets)… different update frequency (continues updates @ HTML level to almost rock solid @ Kernel level) and different skill level and languages.

Yes, through complicated technologies we can get a single system to address all… but do we really gain that much? And is it really one system or one complicated umbrella covering different solutions?

I’ve made a note to do a blog post to go into detail on this, but it’s along similar lines to what you’re saying. In particular, I think that applications have different enough requirements compared to system-level components that there may be value in treating them differently (different packaging, different processes, different user experience)

I think people probably feel safer running Testing than Ubuntu+1 for the same reason they feel safer running Testing than Unstable. I know at least once per cycle I’m left staring at a black screen after a routine update to my +1 system, with the risk reducing as release approaches.

Oh, and yes, PLEASE, PPA’s for Debian. It’s been a wishlist item of mine for years, and is badly needed for collaborative development of stuff. Right now, the only platform that supports it is the openSUSE Build System, and their workflow is shitty from a Debian perspective (it’s really built for a single .spec file, not a debian/ folder)

I think it would be great if Debian used Launchpad, even if it was their own instance. Any particular reason they’re specifically against using Canonical’s instance? My guess is they probably wouldn’t be able to get access to certain stuff on the server they may need to integrate with other Debian services?

It’s mostly a matter of control and independence. Debian (quite understandably) doesn’t want to be dependent on a third-party service in order to run the project. These represent fundamental values in the Debian project.