Re: What can Debian do to provide complex applications to its users?
On 18 February 2018 at 12:14, Colin Watson <email@example.com> wrote:
> * Maybe truncate the frozen dependency tree at C extensions, in order
> that we can make sure those are built for all architectures, so you'd
> still have to care about compatibility with those. It'd be a much
> smaller problem, though.
One case where this truncation would be a challenge is the Numpy and
scipy ecosystem, where the extensions are tightly coupled to blas
library used and the numpy ABI - because extensions built on top of
numpy depend on that ABI. pip has had difficulty shipping binaries of
these stacks because it doesn't represent the ABI - it assumed that
anything with a matching version number was compatible, which isn't
the case. Arguably numpy should do something different there, but it
> * Every frozen dependency must be installed in a particular defined
> path based on (application name, dependency name, dependency
> version), and must be installed using blessed tools that generate
> appropriate packaging metadata that can be scanned centrally without
> having to download lots of source packages.
> * Updating a single frozen dependency (assuming no API changes to the
> application's source code) must be no harder than updating a single
> line in a single file and bumping the Debian package version.
> * Where applicable, deprecation warnings must be configured as
> warnings, not errors, to maximise compatibility.
Perahps its worth adding 'deprecations should be enabled if off by
default - at least during build-time' - I'm thinking of Python where
we (upstream) disabled deprecation warnings and many folk get
surprised as a result.
> * Dependencies with a non-trivial CVE history would have an acceptable
> range of versions, so we could drop applications that persistently
> cause trouble while still allowing a bit of slack. For some
> dependencies it might not be a problem at all; e.g. we probably don't
> care what version of python-testtools something uses.