On 18 February 2018 at 12:14, Colin Watson <cjwat...@debian.org> 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 doesn't :) > * 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. :P -Rob
