On 6/19/05, Steve Langasek <[EMAIL PROTECTED]> 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 > *months*?
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 come December? 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. Cheers, - Michael
