Bug#806824: (no subject)

[Michael Biebl]

Hi Barry,

first of all, would be great if you can block all bugs you filed by this
one, so we can keep track of them more easily and the maintainers of
those packages know that they should hold off until this particular bug
report has been dealt with.

Looking at [1] I see a few packages missing on your list.

Am 11.03.2016 um 15:34 schrieb 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.

Ok, this was misleading. I'll try to explain what I meant in more
detail. Let's take liferea as an example, which currently uses python2.
You asked the maintainer to add an explicit dependency on
libpeas-1.0-0-python2loader, but didn't really explain why.
The maintainer would need to know that he needs to scan all .plugin
files for Loader=python[3] lines, and do that for every new upstream
release.
It's highly likely, that liferea is ported to python3 at some point but
this dependency is forgotten to be updated to libpeas-1.0-0-python3loader.

> 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.

So, I'm not generally against splitting out the loaders, but if we do
so, I think we should automate the dependency generation via a dh_peas
debhelper addon, which scans .plugin files and adds the correct
dependency depending on what it finds.

The alternative I see, is to not split out the loaders, but get the
remaining python2-using packages ported and then disable the python2 loader.

Splitting off the loaders and adding the dependencies manually is a
quick and dirty solution which creates a maintenance burden down the
line. I prefer solutions that potentially require more initial work but
create less work later on.

Regards,
Michael


[1]
https://codesearch.debian.net/perpackage-results/Loader%3Dpython/2/page_0
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20160311/d69baac5/attachment.sig>