On 6/19/05, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sun, Jun 19, 2005 at 01:41:47AM -0700, Michael K. Edwards wrote: > > 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. > > Yes, these are specific examples of packages that will be rendered > uninstallable in unstable by an ABI change on a particular package. Your > claim was that *all* packages "of any great complexity" would be > uninstallable after six months.
Perhaps that reflects my idea of what constitutes "any great complexity" -- a high-level implementation language plus some glue and accelerators in C/C++, maybe a GUI library or two, maybe a module for a separately packaged daemon. I also wrote "without a stack of 'oldlibs'" -- and even packages whose dependencies are completely captured by ldd on a few binaries are going to be in that boat real soon now. > And while perl XSUBs from woody are not installable in sarge, python > extensions from woody *are* generally installable in sarge (for reasons we > shouldn't be particularly proud of, but still). OK; but a program that makes use of them probably doesn't work unless it was future-proofed in advance by systematically avoiding references to "python" without an explicit version. And anything that uses, say, woody's libwxbase2.2 is out of luck. And python-gdbm isn't the version built against python 2.1 anymore, so packages built against it will have the wrong dependencies for sarge. And so on and so forth. > > 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? > > A pathological case if ever I heard one... Maybe so; but then all efforts to use the packaging system to update bits of a language's standard library, without rebuilding (and taking security update responsibility for) the whole shebang, are equally pathological. That would apply to large fractions of CPAN and CTAN and many emacs modes as well as local customizations like my experimental profiler. > > 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. > > Which still doesn't prove a claim that *no* packages will be installable > after six months. What I said was: After six months, I suspect that sid will have evolved to where no binary package of any great complexity from sarge will install on it without a stack of "oldlibs"; and backports will be (as usual) a royal pain. Better just to run a carefully selected sid snapshot. Test your backups frequently, though. :-) Would you settle for "few binary packages of any great complexity", etc.? Cheers, - Michael
