» Re: Ubuntu's Pipe Dream: True Free Software Syncronicity

As Sean Michael Kerner puts it on his blog, Mark Shuttleworth's "The Art of Release".. erm... "vision"/wish/dream/strategy is nether a good nor a realistic thing. Shuttleworth's "vision" just won't work. You can't force 10-20 big upstream projects (KDE, GNOME, kernel, OpenOffice.org, Firefox, GCC, etc...) to sync their release schedule. And you wouldn't want to do that either. One of the reasons why FOSS is usually better in terms of quality is that releases, focus and features are typically driven by quality, by developers, not by marketing and competitors. Things are released when they're ready, when the maintainer thinks it's good enough. Having a synched release plan for many large and complex projects means a huge burden on upstream. I can't imagine Mark Shuttleworth could be that clueless about the reality of software development and how the whole ecosystem around a distribution actually works. He isn't. Can't be. So what agenda is he having/endorsing when he pushes that idea so loudly (arguably, even when he whispers, it does make a lot of noise ;)) ? I don't know. Except, maybe, because Canonical doesn't have much developers working directly on upstream projects that aren't 100% Ubuntu specific (at least compared to Fedora and openSUSE) and hence they're not really in a position to push for certain things to be fixed before others. Well, just thinking out loud, maybe there's no hidden motivation behind it at all. Sean wrote that he rather wished "common packaging across distributions", but:

• PackageKit is definitely a good initiative and project, but it doesn't solve anything with regards to that as it's "merely" a frontend to different package management stacks, so it can give users of several distros the same frontends and user experience, but not access to the same packages;
• it isn't about the package format (RPM vs deb vs whatnot), RPM and dpkg are pretty much equal in terms of features, performance, stability anyway; even if everyone was using RPM, it wouldn't help because the real problem is what dependencies packages are built against, especially their respective versions

To explain the latter: take openSUSE, Fedora and Mandriva, they're all using compatible versions of RPM. So, from a packaging format point of view, you can install an RPM package that has been built on one of those three on any of those three (say, a libfoo.rpm built on openSUSE can be installed on Fedora). Problem is, every single package (except a very, very few) has dependencies against other ones. If you take Firefox as an example, it depends on the GCC C++ runtime libs (libstdc++), gtk2, cairo, freetype, etc... Point is, distros usually don't have compatible (major) versions of those libraries so you won't be able to install openSUSE's 11.0 Firefox package on Fedora 9 because it uses much more recent versions of gtk2/cairo/freetype/GCC/... (just an example). And then you have different package naming conventions (though softened a bit by relying on file dependencies instead of package names for shared libraries). And different init scripts. And different file/directory locations. Distro A uses sysvinit, distro B uses upstart. To summarize, what Sean would like to see is even more restrictive and difficult to implement then what Mark is dreaming of -- it would pretty much boil down to having a single, unique distribution ;) Whatever your distribution of choice is, and regardless about how religious you are about it, I think we all agree that would be a terrible thing, whatever that distribution would be (including openSUSE). In order to accomplish that partially (which should be feasible in theory, certain dependencies are very stable and have a strong record on backward/forward compatibility, e.g. KDE 3), we'd first need to have everyone or at least the "big players" work together on LSB and actually implement it (Debian/Ubuntu don't, or only partly, even without considering RPM), and have LSB evolve at a much faster pace to encompass more standards. If package naming differences and init scripts incompatibilities were addressed and implemented by many distributors, it could be done for a certain amount of packages. Having major upstream projects follow strong guidelines on SONAMEs and ABI compatibility would be a lot more interesting than synching release cycles. But, again, it has a high cost on upstream development, is very complex to accomplish, and clearly takes a lot of fun, drive and "innovation" out of FOSS development. Not sure we'd want that either. I certainly don't. I'd already be really happy if all upstream projects written in C or C++ would know how to properly handle SONAME, bumping the major version number when ABI incompatibilities arise, in order to package and install several major versions of libraries side-by-side (a train openSUSE arguably catched quite late but works for most library packages nowadays). As said, it isn't trivial though, assessing and verifying ABI compatibility through regression tests isn't always that easy -- at least not as easy as with Clirr and/or JDiff when using Java.