please add python3-packagekit package

[Dimitri John Ledkov]

there is no need for this.

[Sebastian Heinlein (glatzor)]

You also need to patch the build system. It currently only supports
building one Python version at the same time.

I took a short look at porting to Python3 for aptdaemon, since we
re-use the packagekit.enums module. But I decided to just ship the enums
in aptdaemon and to drop the python-packagekit dependency.

[Dimitri John Ledkov (xnox)]

Dear Sebastian.

On 13/06/12 16:17, Sebastian Heinlein wrote:
> You also need to patch the build system. It currently only supports
> building one Python version at the same time.
>

Can you please elaborate?

There are no extensions build, yet the autoconf detects libs/cflags/etc
hence it feels like there is a python extension module somewhere. The
pure python module is installed by the upstream build system as is from
lib/python/packagekit/ as is into correct dist-packages location using
automake rules.

Also note that python-packagekit is Arch:all package.

The enums.py is generated, but shipped in the tarball.

At first I did do automake out-of-tree builds with all python2s and
python3s in separate build directories. Only to realise, that actually
this is not required...

From my point I actually see no evidence of 'building' done by the build
system, apart from generating enums.py

> I took a short look at porting to Python3 for aptdaemon, since we
> re-use the packagekit.enums module. But I decided to just ship the enums
> in aptdaemon and to drop the python-packagekit dependency.
>

python3 support was done by upstream, only packaging is required.

Or did I miss something?

Regards,
Dmitrijs

--
Regards,
Dmitrijs.

[Dimitri John Ledkov (xnox)]

I have just dublechecked, the output from 2to3 is actually irrelevant, as all the 'python2/3' stuff is properly taken into with guards which check sys.version at runtime. The python module is bilingual. The enums.py does not seem to depend on which python is used at build time to generate the file.

I am planning to propose to debian to drop python-dev-all and modify the configure.ac to work without it.

[Matthias Klumpp (ximion)]

Hi!
This doesn't look sane to me... If you want to use PackageKit in your application, please use the GIR from Python3, there is no supported version of official Python bindings for PackageKit.
The python-packagekit package is (and should be) only used by backends, client applications need to use the GIRepository.
However, I'll look into the code to see if PK is Py3 compatible (I think it is) and if there's stuff remaining which needs to be done. (we had a few patches for Py3 some weeks ago...)
(Maybe we could even drop the python-packagekit with new releases? - Need to find out more about it...)

[Dimitri John Ledkov (xnox)]

On 13/06/12 23:24, Matthias Klumpp wrote:
> Hi!
> This doesn't look sane to me... If you want to use PackageKit in your application, please use the GIR from Python3, there is no supported version of official Python bindings for PackageKit.
> The python-packagekit package is (and should be) only used by backends, client applications need to use the GIRepository.
> However, I'll look into the code to see if PK is Py3 compatible (I think it is) and if there's stuff remaining which needs to be done. (we had a few patches for Py3 some weeks ago...)
> (Maybe we could even drop the python-packagekit with new releases? - Need to find out more about it...)
>

And I want to transition backends to python3, instead of python2. This
is a first step. It has been identified that python-packagekit is used
in aptdaemon, ubuntu-drivers-common and/or update-manager. This is
inline with the Quantal blueprint to drop python2 from the CD.
Potentially all of that stack should migrate from depending on
python-packagekit, but python3-packagekit is easier to introduce right
now and facilitate with quantal release goal.

See:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions

[Matthias Klumpp (ximion)]

Have you tried to run all stuff with Python3-only? This will probably
already work :-)
What I don't understand: ubuntu-drivers-common and update-manager are
PackageMKit client applications - why don't they use GIR already?
(Maybe there's a communication error somewhere, I'll clarify this
tomorrow and maybe apply some changes regarding Python3-transition to
the Debian package, which you could merge then, if you want. Of
course, feel free to do what you think is good at Ubuntu. (I just
always want to know which changes Ubuntu applies and why))
Cheers,
   Matthias

2012/6/14 Dmitrijs Ledkovs <email address hidden>:
> On 13/06/12 23:24, Matthias Klumpp wrote:
>> Hi!
>> This doesn't look sane to me... If you want to use PackageKit in your application, please use the GIR from Python3, there is no supported version of official Python bindings for PackageKit.
>> The python-packagekit package is (and should be) only used by backends, client applications need to use the GIRepository.
>> However, I'll look into the code to see if PK is Py3 compatible (I think it is) and if there's stuff remaining which needs to be done. (we had a few patches for Py3 some weeks ago...)
>> (Maybe we could even drop the python-packagekit with new releases? - Need to find out more about it...)
>>
>
> And I want to transition backends to python3, instead of python2. This
> is a first step. It has been identified that python-packagekit is used
> in aptdaemon, ubuntu-drivers-common and/or update-manager. This is
> inline with the Quantal blueprint to drop python2 from the CD.
> Potentially all of that stack should migrate from depending on
> python-packagekit, but python3-packagekit is easier to introduce right
> now and facilitate with quantal release goal.
>
> See:
> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
>
> --
> You received this bug notification because you are a member of
> PackageKit-Team, which is subscribed to packagekit in Ubuntu.
> https://bugs.launchpad.net/bugs/1012703
>
> Title:
>  please add python3-packagekit package
>
> Status in “packagekit” package in Ubuntu:
>  Triaged
>
> Bug description:
>  please add python3-packagekit package
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1012703/+subscriptions

[Dimitri John Ledkov (xnox)]

On 14/06/12 00:08, Matthias Klumpp wrote:
> Have you tried to run all stuff with Python3-only? This will probably
> already work :-)
> What I don't understand: ubuntu-drivers-common and update-manager are
> PackageMKit client applications - why don't they use GIR already?
> (Maybe there's a communication error somewhere, I'll clarify this
> tomorrow and maybe apply some changes regarding Python3-transition to
> the Debian package, which you could merge then, if you want. Of
> course, feel free to do what you think is good at Ubuntu. (I just
> always want to know which changes Ubuntu applies and why))
> Cheers,
> Matthias

I think I might be wrong, as it seems that python3-packagekit is not
needed afterall.

I'm trying to get my head around this with help of a few people.

By the looks of things GIR is used....

Regards,
Dmitrijs.

>
> 2012/6/14 Dmitrijs Ledkovs <email address hidden>:
>> On 13/06/12 23:24, Matthias Klumpp wrote:
>>> Hi!
>>> This doesn't look sane to me... If you want to use PackageKit in your application, please use the GIR from Python3, there is no supported version of official Python bindings for PackageKit.
>>> The python-packagekit package is (and should be) only used by backends, client applications need to use the GIRepository.
>>> However, I'll look into the code to see if PK is Py3 compatible (I think it is) and if there's stuff remaining which needs to be done. (we had a few patches for Py3 some weeks ago...)
>>> (Maybe we could even drop the python-packagekit with new releases? - Need to find out more about it...)
>>>
>>
>> And I want to transition backends to python3, instead of python2. This
>> is a first step. It has been identified that python-packagekit is used
>> in aptdaemon, ubuntu-drivers-common and/or update-manager. This is
>> inline with the Quantal blueprint to drop python2 from the CD.
>> Potentially all of that stack should migrate from depending on
>> python-packagekit, but python3-packagekit is easier to introduce right
>> now and facilitate with quantal release goal.
>>
>> See:
>> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
>>
>> --
>> You received this bug notification because you are a member of
>> PackageKit-Team, which is subscribed to packagekit in Ubuntu.
>> https://bugs.launchpad.net/bugs/1012703
>>
>> Title:
>> please add python3-packagekit package
>>
>> Status in “packagekit” package in Ubuntu:
>> Triaged
>>
>> Bug description:
>> please add python3-packagekit package
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1012703/+subscriptions
>

--
Regards,
Dmitrijs.

[Sebastian Heinlein (glatzor)]

Am Mittwoch, den 13.06.2012, 22:24 +0000 schrieb Matthias Klumpp:
> Hi!
> This doesn't look sane to me... If you want to use PackageKit in your application, please use the GIR from Python3, there is no supported version of official Python bindings for PackageKit.
> The python-packagekit package is (and should be) only used by backends, client applications need to use the GIRepository.
> However, I'll look into the code to see if PK is Py3 compatible (I think it is) and if there's stuff remaining which needs to be done. (we had a few patches for Py3 some weeks ago...)
> (Maybe we could even drop the python-packagekit with new releases? - Need to find out more about it...)

Dropping python-packagekit isn't an option. The python-packagekit
package is required by the apt and smart backend. Furthermore it is used
by aptdaemon and the plugins which are available for the apt backend and
aptdaemon (language-selector, ubuntu-driver-common, etc).

AFAIK Smart isn't yet ported to Python 3 so the backend will require
Python 2 for a longer period of time.

The apt backend should actually by Python 3 compatible (except a to be
changed import) but it hasn't worked when I gave it a short look. Needs
some investigation.

language-selector and ubuntu-drivers-common are not only PackageKit
clients: aptdaemon and the apt backend share a plugin system which
allows to modify the dependency resolver and to add WhatProvides
handlers. So language-selector modifies the resolver to ensure that the
language packs for non-default applications get installed and
ubuntu-drivers-common provide mod aliases/driver resolution.