[Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2

[Jonas Meurer]

Hi intrigeri,

thanks for picking up the discussion about mat/mat2 in Buster!

intrigeri:
> Daniel Kahn Gillmor:
>> On Sun 2018-10-07 10:31:13 +0200, intrigeri wrote:
>>> intrigeri:
>>>> What matters to me is the users' perspective. I think we should
>>>> provide a clear, unambiguous transition path and avoid leaking
>>>> technical details to users. So once MAT2 reaches feature parity with
>>>> MAT (I think the only real blocker is the lack of a Nautilus
>>>> extension; MAT v1's seems to be broken on sid currently but it has
>>>> a GUI which mitigates that problem) I think we should:
>>>
>>>>  - Have mat2 conflicts+replaces mat, remove mat from testing+sid,
>>>>    and ship a transitional package called mat that pulls mat2 in.
>>>
>>> IMO we should do that as soon as mat2 installs the Nautilus extension
>>> (#910491).
>>>
>>> Does this make sense to you? Is there a better way to handle this?
> 
>> this all looks reasonable to me as well.
> 
> As Jonas reported on #910491, it's unlikely that mat2's Nautilus
> extension is in Buster. Ouch!

There's still a chance to get it in: if we craft a patch for
nautilus-python that introduces a new package python3-nautilus which is
co-installable (and doesn't conflict) with python-nautilus, then the
nautilus-python maintainer already said that he would consider to accept
it in time for Buster. [1]

That basically means that we have to copy libpython-nautilus.c to
libpython3-nautilus.c, introduce a new extension include path for it
(probably /usr/share/python3-nautilus/extensions/) and patch the build
system to build libpython-nautilus.c only for python2 and
libpython3-nautilus.c only for python3.

Unfortunately I'm unsure whether I find time to work on such a patch
within the next week (which probably would be necessary to get the
package into the archive in time, since it has to pass NEW).

If anybody wants to pick up the work, here's my related PR (which
doesn't do what I explained above yet, but should be a starting point):

https://salsa.debian.org/gnome-team/nautilus-python/merge_requests/1

In mat2, all we would have to do is install the nautilus extension to
the special include path (/usr/share/python3-nautilus/extensions/)
instead of the default one.

[1] In any case, this would be an intermediate solution for Buster.
After buster, the Gnome team plans to start the proper transition from
python-nautilus to python3-nautilus, effectively making all packages
that don't work with python3-nautilus release-critical.

> So it's time to think about contingency
> plans here.
> 
> To me this boils down to this question: do we feel more comfortable
> with:
> 
>   a) including mat v1 in Buster (so less technical can use its GUI,
>      even though its Nautilus extension was broken last time I tried),
>      in addition to v2
> 
> or
> 
>   b) only including mat v2, without any GUI at all (and then add
>      Breaks+Replace, get mat v1 removed from testing, and add
>      transitional package if there's enough time to go through NEW).
> 
> ?
> 
> I'm personally very uncomfortable with both options :/
> But I'm leaning towards not including software when its author
> says it's unsupported and has known (security relevant) issues.

I totally agree here. I think that we should file a RM bugreport for mat
v1 *now* and introduce a transitional package in mat2 regardless whether
we get the nautilus extension for mat2 working in time for Buster.

> Other data points & ideas:
> 
>  - Given the python-nautilus issue essentially requires a transition,
>    I doubt we'll find some way to provide desktop integration for mat2
>    via buster-backports.

See above.

>  - One could quickly patch together a Python 2 Nautilus extension that
>    wraps mat2's CLI, or the simplest possible Python 3 GUI that does
>    not depend on python-nautilus. I'm sure lots of users would be
>    thankful if someone did this. There's very little time left to get
>    this done and through NEW. But it could be an option for
>    buster-backports.

I think the better solution would be to get a working python3-nautilus
into Buster, which *is* possible.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20190129/8ffab11d/attachment.sig>