Bug#806824: (no subject)

[Barry Warsaw]

On Mar 11, 2016, at 07:22 AM, Michael Biebl wrote:

>It creates unnecessary churn and potential stale dependencies in the future.
>Most importantly, this split looks like an implementation detail to me.
>I don't see, why packages should add a dependency on
>libpeas-1.0-0-python3loader but not libpeas-1.0-0-python2loader

I'm not sure about your first point, but as to your last point: it would make
no sense for an application to depend on both loaders.  You cannot load both a
Python 2 and Python 3 runtime into the same address space.

The problem this is trying to solve is two-fold.  First, some libpeas plugins
don't use Python at all, and yet with the old arrangement they would still be
pulling in both Python stacks.  With this change, non-Python plugins wouldn't
depend on either loader package and it would be a clear win.

Python plugins are either going to be ported to Python 3 or not, in which case
they now make explicit which runtime stack they require, via the loader they
depend on, and in fact load at runtime (again, they cannot load them both).
So this is another win because it allows such applications to only depend on
the Python stack they use, and we can better identify which ones need porting
to Python 3.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20160311/30f33db5/attachment.sig>