Merge lp:~unity-api-team/click/drop_packagekit into lp:click/devel
| Status: | Merged | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Merged at revision: | 608 | ||||||||
| Proposed branch: | lp:~unity-api-team/click/drop_packagekit | ||||||||
| Merge into: | lp:click/devel | ||||||||
| Diff against target: |
26 lines (+3/-2) 2 files modified
debian/control (+1/-1) debian/packagekit-check (+2/-1) |
||||||||
| To merge this branch: | bzr merge lp:~unity-api-team/click/drop_packagekit | ||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Alejandro J. Cura (community) | Approve on 2016-02-05 | ||
| Colin Watson | 2016-02-05 | Disapprove on 2016-02-05 | |
|
Review via email:
|
|||
Commit Message
As PK 1.0 does not support plugins anymore, drop the click plugin.
Description of the Change
As PK 1.0 does not support plugins anymore, drop the click plugin.
This should land together with the PK 1.0 transition.
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
> No, this makes click largely unusable in the phone context. The correct
> approach is lp:~mvo/click/native-dbus to implement a D-Bus API of click's very
> own instead of piggybacking on PK; that needs finishing off and landing.
We are forcing packagekit 0.x on the phone context. Therefore the PK plugin will continue to work there, but is not getting build for the main.
| Alejandro J. Cura (alecu) wrote : | # |
Hi Colin,
we took a look at mvo's proposed branch, but we are reluctant of adding a new dbus service running as root just for this, mostly when click will be deprecated when the phone moves to snappy.
So, we decided to keep the older version of PackageKit in the phone overlay, both for vivid and xenial based phones. And to ship the new version of PackageKit in the desktop where there's no use for click's packagekit plugin.
| Colin Watson (cjwatson) wrote : | # |
Well, I'd like to be on record that I think this is a bad idea, because in my experience this kind of divergence always lasts much longer than originally intended, so I'd prefer not to change my vote from Disapprove. However, it's up to you if you want to land it over my objections, since I'm not in charge of this project any more.
On a technical level, this branch is incorrect because it will break dual landings: it will have the effect of disabling PK even if an appropriate version of PK is available in the archive. To fix this, I would suggest restoring the build-dependency on libpackagekit-
Please also fix the indentation so that it isn't confusing (i.e. don't have inner levels at the same level as outer levels). It would be simplest for it to just read:
if dpkg --compare-versions "$packagekit_
dpkg --compare-versions "$packagekit_
echo yes
else
echo no
fi
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
> On a technical level, this branch is incorrect because it will break dual
> landings:
Thanks! I will address these ASAP.
| Alejandro J. Cura (alecu) wrote : | # |
Thanks Colin for your concerns and attention to detail.
I'd like to add that in addition to the risk of introducing security issues by adding a new root service that gets called by userspace code, we believe it's a lot more work adding the new dbus interface because we'd have to modify and retest the phone parts that are used to install click packages: the click scope and the updates page in system settings of the top of my head. And like click itself we are short of maintainers there.
With a change like this we are minimizing the possible disruptions to the phone stack.
- 606. By Antti Kaijanmäki on 2016-02-09
-
return libpackagekit-
glib2-dev build-dep - 607. By Antti Kaijanmäki on 2016-02-09
-
simplify debian/
packagekit- check
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
> To fix this, I would suggest
> restoring the build-dependency on libpackagekit-
> read "libpackagekit-
> glib2-dev (<< 1.0.0)" instead.
done.
> It would be simplest for it to just read:
>
> if dpkg --compare-versions "$packagekit_
> dpkg --compare-versions "$packagekit_
> echo yes
> else
> echo no
> fi
done.
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
> "libpackagekit-
Actually, does this also get satisfied on a system (near future xenial) that only has libpackagekit-
| Colin Watson (cjwatson) wrote : | # |
Sorry, this was a silly typo - apparently I got distracted half-way through typing those dependencies. I meant to say:
libpackagekit
This is logically equivalent to "(libpackagekit
- 608. By Antti Kaijanmäki on 2016-02-10
-
fix build-deps
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
> Sorry, this was a silly typo - apparently I got distracted half-way through
> typing those dependencies.
np. should be fixed now :)
| Antti Kaijanmäki (kaijanmaki) wrote : | # |
@cjwatson: anything else that needs amending?
| Colin Watson (cjwatson) wrote : | # |
Assuming it builds sensibly, I think it's technically OK at this point.
No, this makes click largely unusable in the phone context. The correct approach is lp:~mvo/click/native-dbus to implement a D-Bus API of click's very own instead of piggybacking on PK; that needs finishing off and landing.