Tuesday 8 March 2016

Re: Knocking Python 2 off the desktop iso

Thanks Till for taking care of system-config-printer.

On Mar 08, 2016, at 09:53 AM, Dimitri John Ledkov wrote:

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

Samba does indeed call back into Python via C code. What I was told:
"Unfortunately, libsamba-python is not isolated. We have C code that calls out
to Python - e.g. libsamba-net depends on libsamba-python and code from
python-samba through that."

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

Yep.

># 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
>samba-libs
>0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
>
>Should we split:
>/usr/lib/gvfs/gvfsd-smb
>/usr/lib/gvfs/gvfsd-smb-browse
>
>Into a separate package? Or should we tweak samba-libs splits to make
>samba client side things usable without libpython2.7? Is that even
>possible?

I am not an Samba expert, but my understanding is that it's not possible.

With today's pending desktop image, if you purge libpython2.7, python,
python2.7, python2.7-minimal, and libpython2.7-minimal, you'll get rid of
gvfs-backends, python-talloc, libsmbclient, and samba-libs. Unfortunately
then nautilus can't connect to smb:// servers; you get an unhandled error
because /usr/lib/gvfs/gvfsd-smb-browse is missing, as you imply above. You'll
get the same with rhythmbox when you try to connect to a Windows Network (via
+ Other locations), which of course makes sense.

I wonder how crazy it would be to have a stub/alternative
/usr/lib/gvfs/gvfsd-smb-browse which when invoked prompts the user to install
the real gvfs-backends via pk? Then we'd Depends nautilus and rhythmbox on
this package (it could even be a little Python 3 app :) and get both for free,
as well as anything else that might reverse-depends on it?

I know this makes things less friendly for people who need Windows resources,
but until Samba itself gets fully ported, our choices are rather limited: keep
two Python stacks on the desktop image or provide a hook to install the
required packages when needed.

Cheers,
-Barry