Re: PackageKit FUD, Was: External dependencies, DeviceKit-power and GNOME Power Manager

On 11/25/08, Josselin Mouette <joss debian org> wrote:
> Le mardi 25 novembre 2008 à 17:36 +0000, Richard Hughes a écrit :
>> On 11/25/08, Josselin Mouette <joss debian org> wrote:
>> > It is also very unlikely that Debian embraces PackageKit as long as its
>> > target feature set is stick to the RPM capabilities.
>> Please don't spread FUD, it's just not true. Please do some research
>> before making ridiculous claims like that.
> That's no more FUD than what you said about Debian tools [0], so let's
> say it's a misunderstanding to remain polite.

No misunderstanding, sorry. APT is the only packaging system that formally _requires_ free input from the user, blocking in the transaction. If as much effort was put in to fixing the deprecated behaviour of some packages as arguing about how to ask questions in PackageKit, they would all be fixed now.

PackageKit does allow you ask certain questions, in a _structured_ way, something like this:

It just won't open a terminal. Opening a terminal as the root user would be so broken for a GUI tool. Note, an admin can still use the apt command line in a terminal, if the package "won't install" using the GUI tools.

>> At the moment, PackageKit
>> works with apt, alpm, box, conary, opkg, pisi, poldek, smart, urpmi,
>> yum and zypp. It even has functionality that cannot work with rpm and
>> yum, so this really isn't an RPM focused thing...
> Supporting APT is one thing, but supporting what other APT frontends do
> is another one. As long as you restrict the feature set to the lowest
> common denominator, my remark holds.

Sure, PackageKit doesn't aim to replace all the functionality of all tools, for that would be insane indeed. Power users don't have to do everything in a GUI. As an aside, I'm still not completely sure what features you think PackageKit doesn't have.

> Currently it deliberately violates
> our policies despite all attempts at discussing it, and it would be kept
> out of the testing branch as soon as it is uploaded.

Right, sure, it violates an arcane spec that says a package manager should provide a VTE for packages that don't use debconf. This was my design decision and totally deliberate as it would make most of the cool-stuff impossible.

> I do not deny the application design of PackageKit is orders of
> magnitude better. Still, that doesn't make it any better in terms of
> features.

If there's some thing specific, I would ask you to email the PK mailing list, and we can discuss there; this is way off topic for DDL.

> As I already stated, I have much interest into bringing PackageKit to a
> level where it is usable for Debian. I've joined the mailing list even
> though I'm too busy to follow all of it. However, the hostility I have
> encountered so far is not encouraging. I don't think Debian currently
> has the resources to maintain a full fork after the necessary code has
> been written.

You don't have to fork PackageKit to make it "work" with Debian, you just write a backend and fix your spec. Ubuntu are quite prepared to work _with_ the PackageKit developers rather than _tell_ us what legacy features we have to support.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]