Re: Debian concordance
Scott James Remnant <firstname.lastname@example.org> 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
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
> 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
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@example.com) <http://www.eyrie.org/~eagle/>