Re: Debian concordance
On 6/18/05, Joey Hess <joeyh@debian.org> wrote:
> Matt Zimmerman wrote:
> > Practically speaking, the differences in compatibility between Ubuntu and
> > Debian is of as much concern as those between Debian stable and Debian
> > unstable. New interfaces are added in unstable constantly, and software is
> > adapted to use them. Binary packages from unstable are rarely installable
> > on stable without upgrading other supporting packages. Third party
> > packagers must choose whether to provide builds for stable (if the package
> > builds), unstable or both. So far, this has not resulted in a problem for
> > Debian.
>
> Except unstable is capable of running packages built on stable, and
> stable is to some extent (partial upgrades) capable of running packages
> built on unstable. And if it doesn't work, a dependency will tell you it
> doesn't work. And Debian is able to decide we want to make it work better
> and fix things. So I don't think your analogy holds up very well.
After six months, I suspect that sid will have evolved to where no
binary package of any great complexity from sarge will install on it
without a stack of "oldlibs"; and backports will be (as usual) a royal
pain. Better just to run a carefully selected sid snapshot. Test
your backups frequently, though. :-)
But Joey's right that having two "stable" releases, neither of which
has systematically greater version numbers than the other, complicates
the graph a lot. This isn't necessarily a problem; in a way, it's a
nice business opportunity for people with a good grasp on the whole
process to build customized distros for businesses that need them for
embedded / ISV purposes. But that opportunity already existed
mid-Debian-release-cycle; it's just sort of changed shape.
A former client of mine was very appreciative of the glibc
2.2.5-final-that-never-was build that I did for them (extending the
useful life of their woody systems, for their particular purposes, by
a year or so). In a hypothetical similar situation six months from
now on sarge, I would probably suggest that they try breezy for a
while rather than go custom; but they would need custom work from a
different angle to port their internal code "sideways" and re-tune
their automated install procedures. And it works both ways, of
course; developers who jumped immediately to hoary may decide that
they want python 2.3.x by default after all, and need help persuading
sarge to play nice with multiarch.
It's dull work in some ways, but it's bread and butter for the local
distro wrangler. I'd sure rather have several Debian-style arrows in
my quiver than have to choose between Good Luck Enterprise Linux
flavors R, S, and W. :-)
> > The cost of guaranteeing ABI compatibility is high, and the benefit to free
> > software is marginal. It is a problem for proprietary software vendors to
> > be concerned with, and we should leave it to them. We have more important
> > work to do, and we're doing it in source code form.
>
> If I were only interested in source code, I would not be a contributor
> to this distribution. I am interested in whole, working systems which
> are accessible to end users.
Amen, brother. But Ubuntu's end users shouldn't be pointing their
sources.list at J. R. Hacker's apt repository, even when J. R. Hacker
is pronounced "Debian", and vice versa. On the other hand, I
respectfully differ from Matt about whether the creation of an
ISV-friendly build environment should be left to ISVs. Coaxing, say,
a major proprietary RDBMS vendor onto Debian/Ubuntu, and reaping the
benefit of their benchmark-driven advice in tuning our kernels and
libraries, would benefit everyone, including those who prefer
open-source databases.
> > "Debian packages just work, in the environment for which they were intended"
>
> No, Debian packages just work, if dpkg allows you to install them on
> your system.
>
> Unless, now, they happen to be built by someone running the other
> distribution.
I can think of several ways that this could happen, but I haven't
actually seen any of them yet. Would you mind adducing some examples?
> > This has nothing to do with binary compatibility, and everything to do
> > with rigorous packaging practices (which is the true basis for this
> > selling point).
>
> I agree that ABI compatability is only part of the picture, though it
> seems like one of the more important parts. However, the other parts of
> the picture suffer from similar problems.
It's important if you like, say, sarge for compile farms and hoary as
a base system for demo LiveCDs.
> Just as a random example, Ubuntu's fork of debhelper has a hack[1] in
> dh_buildeb to run pkgstriptranslations, an Ubuntu-specific command which
> removes mo files from usr/share/locale. That works ok until Debian adds
> a pkgstriptranslations that does something else. Or until the Debian
> version of debhelper is installed on someone's Ubuntu system and begins
> building packages without calling this tool.
I agree with Joey that mucking with the actual packaging system (or
even a very popular helper kit) is one of the more fork-like things
that a derivative distro can do. But this is certainly an area where
sarge+hoary is no worse than woody+sid-after-twelve-months was; many
backported source packages were broken in gross or subtle ways if you
didn't start by building yourself an up-to-date debhelper.
> > It has never "just worked" to mix and match binary packages from
> > different releases of Debian, or packages from different Debian
> > derivatives.
>
> No other distribution has ever seen the need to fork debhelper (and
> modify/fork 1500 other packages), or recompile the entire Debian archive
> from scratch. No other distribution except perhaps Knoppix has attracted
> enough users and developers to make compatability issues more than minor
> annoyances. People didn't start talking about "rpm hell" until Mandrake
> or the like showed up.
Here I can disagree from experience. RPM hell is being unable to
reproduce your vendor's binaries as a starting point for subsequent
modifications (with or without third-party help), and it was already
gaping wide as of Red Hat 5.2. Competitive pressure from Mandrake
definitely helped, although not enough to give me any reason to
question my preference for Debian when I have the option.
Ubuntu is the first Debian derivative not to be more or less a random
sid snapshot plus the deriver's pet hacks. I don't mean that
pejoratively -- every DD's dev box is a random sid snapshot plus pet
hacks -- but actually going through a stabilization and release
process takes manpower and organization, and Ubuntu is the first
derivative to begin to approach Debian on either scale. If you think
about it, you will realize that it's no coincidence that their more
intrusive changes are in the areas of i18n/l10n and auditing the
archive's self-hosting-ness. Why not celebrate the fact they they are
exercising the freedoms to which Debian contributes so much?
Cheers,
- Michael
Reply to: