On Wed, 3 Oct 2018 at 10:44, Neil Williams neil.williams@linaro.org wrote:
On Wed, 3 Oct 2018 at 10:24, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Mon, 1 Oct 2018 at 10:46, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Mon, 1 Oct 2018 at 10:24, Neil Williams neil.williams@linaro.org wrote:
> Is there any reason why lava is stuck with debian? Why not package it > as pip package and make distro agnostic?
This is covered in the docs. LAVA has dependencies which cannot be provided by pip and it has functionality which pip cannot support.
It turns out debian isn't any better in managing dependencies here.
That's an unhelpful description of the situation - there's been no request to put this change into stretch-backports. Stretch is a stable release, changes don't go in without a reason. Other people using this package in Stretch have obviously not had problems with the version in Stretch.
maybe there is no one using it. It fails as soon as you include it into django settings.
milosz
In order not to implement all filtering again I tried using django-filter package. Unfortunately the version that is currently in stretch (0.13.0-1) has a bug [1] that is fixed in 1.0.2. So buster version (1.1.0) is OK. There is no fix in stretch-backports. Any hints what to do in such case?
We can request an upload to stretch-backports of the fixed version in buster. This is how Debian works - packages in testing (currently buster) can go into stable-backports (currently stretch-backports), once that work is requested.
That gives us a change of limited impact which can be properly staged, validated and implemented and which won't change underneath us later.
[1] https://github.com/carltongibson/django-filter/issues/673
milosz
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/