On 4 March 2016 at 19:27, Barry Warsaw <[email protected]> wrote:
> A long standing goal for Ubuntu has been the demotion of Python 2 off of the
> default installation images. This is something many folks have been
> working on for quite a few cycles, and it's finally within our reach for
> desktop (server and touch already have no Python 2 on it). Of course this is
> within the context of a much longer term, cross distro effort to port the
> entire world to Python 3 <wink>.
> We have one last thing holding Python 2 on the desktop image, and it's a
> problematic one: system-config-printer. Actually s-c-p is already itself
> ported to Python 3, but it transitively depends on Python 2 through the chain
> of python3-smbc -> libsmbclient -> samba-libs -> libpython2.7. So the real
> problem is fully porting Samba to Python 3. Ubuntu is not the only distro
> converging on this bottleneck.
The chain is a bit more complex than that.
samba-libs -> python-talloc -> [python, libpython2.7]
That chain looked odd to me. Is samba somehow embedding python
interpreter and using it by default? Cause surely it shouldn't need
unless something like python-samba is used.
It looks like python-talloc ships a public shared library and a python
extension. And samba-libs links with the shared library. Splitting the
public library out of python-talloc, should get us to dropping the
interpreter. I think.
But going back surely samba libraries that are used via python only,
can be somehow isolated into e.g. samba-libs-python or some such, no?
BTW. nautilus & rhythmbox pull in gvfs-backends, which pull in samba stack too.
# apt remove python2.7
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
gvfs-backends libsmbclient python python-crypto python-ldb
python-samba python-talloc python-tdb python2.7 samba-common-bin
0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
Should we split:
Into a separate package? Or should we tweak samba-libs splits to make
samba client side things usable without libpython2.7? Is that even
> Clearly, we won't have an untangled the Samba stack in time for 16.04. I'm
> proposing instead to demote python3-smbc to a Suggests for
> system-config-printer, which should drop it from the desktop image, thus
> allowing us to purge libpython2.7, python2.7, and python.
> The downside of course is that you won't be able to automatically detect
> Windows printers after a default install. For users who don't have network
> attached (e.g. IPP) printers, that's a hardship. The question is whether
> there are enough users who fall into that category to outweigh keeping the
> full Python 2 stack on the image.
> There's a middle way perhaps. It's not fantastic, but there is precedence.
> In a similar situation, deja-dup depends on duplicity which has not yet been
> ported, so in order to do backups, deja-dup exposes a button to install some
> additional packages. That of course pulls Python 2 back in, but it does at
> least keep the desktop iso smaller and doesn't affect anybody who doesn't want
> to do backups.
> In a similar way, we could do a runtime check in system-config-printer to see
> if the python3-smbc library is available, and if not, expose a button to
> install the necessary package if the user wants to search for a Windows
> printer. There are already places in the code that catch ImportErrors if the
> Samba-requiring bits aren't available, so s-c-p should continue to work
> without it. That would allow us to knock Python 2 off of desktop, and users
> without Windows printers could ignore the reduction in functionality, while
> users with Windows printers would at least have a discoverable path to adding
> that functionality back.
> Given how close we are to completing this long-term effort, I'd vote for just
> the Suggests demotion or adding the button. But I'm admittedly biased. :)
>  https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
>  LP: #1552868
>  At least, via deja-dup! We all do regular backups, right?! :)
> ubuntu-devel mailing list
> [email protected]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel