Infrastructure vs. Interface
pgoetz at mail.utexas.edu
Thu Jul 2 18:40:51 UTC 2009
> 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.
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
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_22.214.171.124 and you only have libncurses_126.96.36.199
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.
More information about the Ubuntu-devel-discuss