On Sun, Jun 19, 2005 at 05:19:08PM +0100, Scott James Remnant wrote: > > > 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. I thought the big problem was that the Helix GNOME packages were packaged without any coordination with Debian, and no effort was made on the part of those packagers (and therefore, not by anyone else either) to ensure the official Debian packages for woody included a smooth upgrade path? > 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). Sure there is -- Provides: bzgrep But that requires coordination between the maintainers of the two packages. And while file-based dependencies could address this particular class of issue (and I think there's far from universal agreement that it's a good idea), there are certainly other issues where packaging system changes can't possibly be a substitute. It's also certainly not realistic to expect Debian maintainers to track down whatever arbitrary changes any Debian derivative is making to their packages: there are far too many Debian derivatives to go around. So yes, when Debian derivatives make changes without communicating with Debian about them, I do blame the derivatives for the resulting incompatibilities. > 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. And do you have any real-world examples of this happening? Patching upstream libraries in this fashion is strongly discouraged within Debian. Even glibc, which seems to have started this discussion, hasn't suffered from such a problem between Debian and Ubuntu. > 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. I think that's a very unrealistic position to take. If the derivatives care about breaking compatibility, why aren't they here *telling* us when we've done something wrong? And if upwards compatibility isn't a priority for them, why assume that this is any fault of Debian's? -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature