Re: Debian concordance
On 6/19/05, Steve Langasek <email@example.com> 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
> 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
> > 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.?