Infrastructure vs. Interface

[Patrick Goetz]

> Date: Wed, 01 Jul 2009 09:57:01 -0300
> From: Felipe Figueiredo <philsf79 at gmail.com>
> Subject: RFC: binary compatibility between short cycles
> To: ubuntu-devel-discuss at lists.ubuntu.com
> 
> Infrastructure could be kept at stable versions for longer cycles, and
> Interface would match the usual 6 month release cycle. Infrastructure
> would be loosely defined as 'whatever needs to be kept to provide binary
> compatibility' (glibc and friends).
> 
> Some major benefits I can see in this, is that if you share the
> Infrastructure packages between cycles, it reduces maintenance
> resources, mirror storage usage, smoothen dist-upgrades and offer third
> party developers a more stable environment, while still giving users the
> latest Gnome (and KDE), Mozilla, etc.
>
 > Comments?

The counterexample to this can be found in the just posted Pulseaudio 
v0.9.16~test1 availability announcement:  Everyone seems to agree that 
audio on linux needs to suck less, so upgrades in this area are vital, 
yet this version of Pulseaudio depends on the 2.6.31 kernel.  If the 
kernel isn't in Infrastructure, then what else could be?

The problem with this idea in general is that most people always want 
the newest, latest and greatest stuff.  Just reading about the 2.6.30 
kernel here:
http://www.h-online.com/open/Fine-tuning-What-s-new-in-Linux-2-6-30--/features/113478
makes me wonder how I ever lived without it -- only a fool would use 
2.6.28! <:)  There is just as much if not more critical development 
going on at the infrastructure level (the kernel, filesystems, 
HAL->DeviceKit, etc.) as there is at the application level.  I care a 
lot more that my ext4 filesystem doesn't completely lose a file that 
I've been working on for 8 months and just saved than I do if the 
installed Firefox is 3.0.14 or 3.0.19.

Also, what does stability at the binary level for third party developers 
mean?  I think you're taking it to mean that the underlying packages 
stay the same, but this is the wrong level of granularity, IMO.  What's 
important for third party developers is that the API's stay the same. 
Of course this is a tricky issue:  maintaining backwards compatibility 
is another word for keeping obsolete, crufty old code in your system; 
it's usually better to make a clean break whenever possible, otherwise 
you become MS Windows still trying to run DOS code, or, even worse, 
Microsoft Office, with thousands of blocks of undocumented, 
unmaintained, unmaintainable binary code (I think they call these 
"extents" -- sort of like calling poop "soil enhancer") which is in the 
code base to allow, say 10-year old Excel spreadsheets to be displayed. 
  (Look no further than this example to determine that open standards 
like HTML, XML, and ODF are good, btw.)

One area where I agree that there is considerable room for improvement 
and something that would have to be fixed in order for your idea to work 
is package dependencies. Currently most people use stuff like debhelper 
to build packages, which means AFAIK that dependencies are set against 
the currently installed packages on the machine on which the package is 
being built, which usually translates into dependencies that are 
stricter than they need to be.  In the Real World(tm) I often find 
myself working on a project where I must have feature X in application 
Z, which is only available in version N+1, while version N is available 
in the installed distro.  No problem; I go to the package pool for 
distro-newer, grab version N+1 of application Z and try to dpkg -i it, 
only to be told something like "unmet dependencies:  this program 
requires libncurses_5.7.1.2 and you only have libncurses_5.7.1.1 
installed."  For reals?  Sorry, I'm skeptical.  Of course I can download 
the source package and use dpkg-buildpackage, but at this point you lose 
about 90%+ of whatever users were still left trying to solve their 
problem in a somewhat sane fashion.

Agreed that optimizing dependencies is a fiendishly hard problem to 
solve, but it would be nice if the dependencies set were a little closer 
to the actual dependencies rather than the "sufficient" dependencies. 
In any case, I don't think your idea would work with the way most 
maintainers build packages today.