Monday, June 24, 2013

Cascaded builds - solution or a problem?

Fedora 19 consists out of approx 14000 of packages. Could you imagine a situation, where a security fix for one basic package (let's say kernel) would cause a need for the 14000 packages rebuild*?

It sounds strange.

On the other hand, it is perfectly normal in the Eclipse world. Let's imagine that I want to put a new EMF into my Eclipse platform. So I need to build EMF, and put it into Eclipse (a.k.a. rebuild platform with proper update sites). The whole process takes quite some time, but that's not that important.

If EMF had any dependencies, I'd have to rebuild them first.

So I've started investigating how to automate those tasks. And this is an answer I've received:
[...] From my point of view, these Java module frameworks refuse to acknowledge that  there is extensive experience with distro-level release engineering. (Basically, exact dependencies and multiple versions of the same code might be convenient now, but will seriously hurt you down the road.) [...].
Florian Weimer.
Full text in the fedora-devel.

The part about strict dependency check struck me as being "just right". Eclipse definitely needs a very strict checking at the build time and during changing the installation.

But it does not, and should not be very strict about components being changed at runtime.

And yes, rebuilding the entire Eclipse to get a minor security update in one of it's dependencies is a waste of time.

So I've put up a small wiki page in which I described how I'd like to see installation handled.

The link to the wiki page.

Any comments welcome.

* such situations happen, although very rarely, especially when there are big changes done in compilers, but this happens only when a distro was not released yet.

EDIT: corrected typo and link to fedora-devel.


  1. It should be easy to manually update single bundles but there seem to be two things kind of preventing that:

    1) The p2 user interface almost exclusively focusses on features, i.e., your distro-level components. The p2 director can install/update any type of component.

    2) Most features are defined to include components with zero-width version ranges, which means that slightly different versions of your hotfix bundles are considered incompatible. The only way to tackle this (and that I know of) is to use feature patches which can replace selected components (versions) in the original features. I find this cumbersome.

    1. Hmmm...
      Maybe it could be possible to generate feature patches on the fly?