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?
Attachment:
signature.asc
Description: This is a digitally signed message part