On Sun, 2005-06-19 at 11:42 -0400, Joey Hess wrote: > Scott James Remnant wrote: > > Walking up to a "man on the street", if anything, you'll find Debian has > > a far worse reputation than RPM and RedHat-derived distributions. The > > general feeling is that third-party RPMs will almost always install on > > any system, while third-party .debs are practically useless. > > That's strange, this is not the impression I've gotten from ten years of > reading the debian-user mailing list, participating in Linux and Debian > user groups, or hearing people discuss services such as backports.org > and apt-get.org, or from using them myself. > Try hanging out outside of the immediate Debian community; I spend a fair amount of time loitering around the GNOME and Freedesktop.org communities, for example. You see a wildly different picture there.
> > A definitive example would be the (eventually abandoned) attempt by
> > Ximian to provide debs for Helix GNOME.
>
> Didn't that have more to do with it being experimental, rather flakey,
> and conflicting badly with the gnome stuff in Debian?
>
The main problem they had was that they created the debs for potato, and
they were perfectly installable on that. But Debian changed things
hugely in unstable, so they weren't installable there -- and then
introduced testing, making three incompatible systems.
It was impossible to create a single set of debs that would work on all
three (stable, testing, unstable) distributions of Debian at the same
time.
There are some fundamental technical problems with the way Debian does
things, and the way our software works, that makes deriving from Debian
or providing third-party debs very hard or impossible. Unfortunately
Debian has a habit of blaming the derivative or third party for working
around these problems :-(
Let's use a popular example... I make a package that
requires /usr/bin/bzgrep.
In Debian, I would have to read the debian/changelog for bzip2 and
discover that this wasn't introduced until 1.0.1-3, and thus
Depends: bzip2 (>= 1.0.1-3)
But in a Debian-derivative with a different release schedule (perhaps a
system used in Schools and sync'd on the start of a school year), that
might have been backported and added in 0.9.5d-3school1
Depends: bzip2 (>= 0.9.5d-3school1)
There's no way to express both of these relationships in the same binary
(as 1.0.1-2 would satisfy the relationship for the Debian-derivative).
In the RPM world, my package can simply depend on the
file /usr/bin/bzgrep existing.
Similar problems exist for shared libraries, I might need a symbol added
in a particular revision in one derivative and a different one in
another.
I don't disagree with, and in fact, I utterly support the idea that
Debian should be an excellent base for derivative distributions and
third-party packages. I just don't think sarge is there, in fact, I
think sarge is about as far from that ideal as you can get.
We need social and technical changes to make Debian suitable as a
"standard base", I think we should do it and I think we _can_ do it.
But first Debian needs to stop blaming derivatives and third parties for
breaking compatibility, and instead ask what we did wrong that required
them to break compatibility in order to reach their goals.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
