Re: Debian concordance
On 6/19/05, Steve Langasek <email@example.com> wrote:
> Of 596 "lib" packages in woody (loosely identified), 325 are still
> present in sarge. That's after three years of more or less constant
> development. Where did you come up with this absurd idea that all binary
> packages "of any great complexity" will become uninstallable after only six
The examples that come to mind immediately are those with substantial
components in both native code and an interpreted or bytecode
language, such as Perl XSUBs and Python extensions. Last time around,
I seem to recall that Perl was updated shortly after the release, and
you couldn't very well install a binary package containing a Perl
module (especially an XSUB) without also installing the old Perl, by
which time you might as well have a stable chroot. And what are the
odds of my tweaked Python profiler, built to divert individual files
within the Python library tree, working with sid's stock Python build
The next example to pop into my head is the Midgard content management
framework, which involves both an Apache module and piles of PHP code.
The chances of a binary package built on sarge installing (let alone
working) against next year's apache and php packages in sid probably
aren't that high.
The fact is that, while the C dynamic library naming system and the
split into libfoo2 and libfoo-dev allows multiple historical versions
to co-exist, the same cannot be said of all languages and development
frameworks. Biggish software packages tend to have a few too many
paths and versions compiled into them to survive the first six months
after a release without source code changes and recompilation. Think,
say, the LyX WYSIWYM front end to LaTeX (which knows the paths to all
sorts of document format converters) or a build of gvim with all of
the scripting language bells and whistles.
Doubtless others who have had more occasion to attempt this sort of
thing than I have will provide more examples if needed.