On binary compatibility
I've read a lot about the binary incompatibility concern between
Debian and Ubuntu. I have an idea, but I don't have the skill to
implement it myself. I figured it would be useful to throw it out
there for you all to scrutinize, determine the implementation
feasibility, and perhaps run with.
First of all, I think it is useful to analyze Ubuntu's motivation --
releasing well-integrated bleeding-edge software. The easiest way to
accomplish this goal is by branching from sid. This means that Ubuntu
libraries differ from the stable Debian release. Hence, Debian stable
(and sid/testing) packages are incompatible with the Ubuntu libraries;
thus creating the need for duplicate packaging work by both the Ubuntu
and Debian communities.
I think that Ubuntu's motivation to provide the latest software is
reasonable; however, I think that Debian may be able to help to
support that goal while making it possible to maintain binary
compatibility.
The solution would be to convince Ubuntu to branch from stable instead
of sid. The problem is that this creates a lot of work for Ubuntu
because they have to backport all of the desired bleeding-edge stuff.
However, Debian developers could work with and contribute more to
backports.org making it easier for Ubuntu. The most problematic
software will be GNOME because it depends on the latest GTK which
depends on newer low level libs, which would mean all of the above
would need to be backported -- probably quite a significant
undertaking. Maybe a solution would be to force the sid GNOME release
(and hence the upstream GNOME) to use the Debian stable GTK.
Obviously this would have some major political issues. How can we
tell upstream what libraries they can and cannot use? Hardware
support would be another issue. There would need to be a way to
backport support for newer hardware, which may involve backporting
newer kernels or backporting support for newer hardware into the
stable kernel.
The problem is that this solution is hard work for Debian, and I don't
think that Ubuntu would take on the backporting challenge itself. It
also means making backports.org an official Debian archive. The only
way that this would work is if there are Debian folks willing to spend
the time to work on backports of their packages. And there would
need to be coordination with Ubuntu to determine which packages
require backporting, and which can be kept as is.
Well, anyway, these are my thoughts. I'm not a developer, and thus
cannot see the issues beyond those described, and cannot take on this
work myself, but I think that compatibility is a very desirable goal
-- not only for Debian and Ubuntu, but for providing a stable platform
for external software development on GNU/Linux. All too often I hear
about "we don't support Linux because it's a moving platform," and "we
can only support one version, so we choose red hat enterprise 3". I
think thats rediculous. I think we can make it possible for software
developers to create one release that will run on all distributions.
One final open-ended question is: which consumes more resources?
Duplicate packaging or backporting?
I look forward to any insight and contributions.
Mike Gilbert
Reply to: