Scott James Remnant <[EMAIL PROTECTED]> writes: > 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. So build three sets of .debs. I'm not sure why people would consider that so hard? Debian provides a ton of excellent tools to help you do exactly that. You have to learn pbuilder and set up a couple of chroots, which while sounding intimidating is actually a matter of a couple of hours work to produce an environment that will then serve you well for years and is quite easy to maintain. Certainly you're not arguing that one never has to build multiple RPMs, are you? Most software I use that provides RPMs has multiple variants for similar reasons (one for Fedora, one for RHEL3, one for RHEL4, etc.). > 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). This seems like an extremely artificial example. Why would the school distribution backport a new feature to a release that's supposed to be extremely stable? > In the RPM world, my package can simply depend on the file > /usr/bin/bzgrep existing. I can see the merits of this feature in some circumstances (among other things, it means not having to work out the alternative packages that supply a particular binary and don't provide a virtual package). I wouldn't object if someone found a way to make it work well with Debian. You still will need to list what package to install to get that file if you don't already have it, though; I really don't like the idea of apt-get using apt-file to try to guess at what package to install to satisfy the dependency. RPM used to use this mechanism for libraries as well; I sure hope you're not proposing that, as Debian's method is far, far more reliable. > 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. Well, this I can mostly agree with, since I don't think blame is usually the right way to approach these sorts of things. I'm not sure that blame is really what's going on so much as concern, and I do think the concern is warranted. Certainly, if there are infrastructure improvements that Debian can make without sacrificing its quality that make it easier for derivative distributions to not diverge, I'm all in favor of that and will help as much as I can. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
