PackageKit Critique

If you haven’t heard, PackageKit is an exciting and upcoming project who’s goal is to create a user friendly package handling abstraction layer that is independent of distro and package format. Basically, the Grand Unified Package GUI for those more physics-minded. Sounds good like a good idea.

There are a few problems I have with the way PackageKit is heading, though, and hopefully this is a constructive critique that may help people think about these issues. I’m not a package management expert and I’ve only used PackageKit a bit on the soon-to-be-released Fedora 9 so please shout out if I get my facts wrong.

  1. The PackageKit FAQ and people promoting PackageKit seem to often say something along the lines of “we’re not trying to replace <existing package management tool>“. I can’t help but think that, if it’s not designed to replace anything, is it really going to be all the unifying? If we’re gonna come up with a good distro-agnostic package management GUI it’d be nice if it actually replaced all the existing tools. Put another way, shouldn’t “unifying” package management imply replacing the disjointed bits that currently exist?
  2. Another thing I’m having an issue with is the proposition that PackageKit is distro-neutral and is not trying to change existing “low-level” tools (apt, yum, etc.). However, discussion around the apt backend, Hughsie’s Law: “Authentication or license prompts can only be done before the transaction has started, and messages or notices about the transaction can only be shown after the transaction has completed.” and a similar FAQ statementUpgrading, installing or removing packages has to be 100% silent.” indicate to me that perhaps it isn’t as neutral as it claims to be. Basically, PackageKit is neutral as long as your view of package management is the same as PackageKit author’s.
  3. There are several places in the PackageKit FAQ and Debian wiki discussion where the PackageKit authors seem to indicate that simply erroring out of the transaction is a suitable, even if non-ideal, solution to problems that PackageKit can’t seem to cope with. I can’t think of anything more user-unfriendly than to have a package management tool bail because it can’t handle certain classes of packages (for instance packages that have a EULA, need input from users, or ask about config file changes). Users would assume, I would think, that the package is somehow broken and would either give up or report a bug to the distro.

I guess I would summarize by saying that it seems to me that PackageKit is painting itself into a corner where it is only useful to subsets of users and packages, while trying to still maintain that it is a unifying and user friendly tool. I see a lot of potential in PackageKit and appreciate all the time put in by Richard Hughes, but I’m not sure at this point how it’s going to reach it’s goals. Perhaps a more knowledgeable person can help enlighten me. 🙂

Advertisements

18 thoughts on “PackageKit Critique

  1. Excellent points and about the same as I feel as well: with those goals and “laws”, PackageKit risks *adding* to the confusion instead of helping it. As it is only designed for a certain subset of packages and situations, many (or most?) users will have to, upon occasion, run another application (GUI or command line).

    So, instead of drilling down from apt/yum/whatever, we now get apt+pkgkit/yum+pkgkit/whatever+pkgkit…

  2. Hey, good critique – I appreciate the time to review this sort of stuff.

    1) The point about not trying to replace the existing tools is that some people are quite fond of them, and still want to still use them. For instance, some people really like the pirut UI (!) and want to still use it in F9 – but by default pirut is not installed. So it’s effectively replaced it, but it’s not mutually exclusive with PackageKit — the two can work together if they need to. Maybe I’ve been unclear in the FAQ.
    It’s a similar story with apt-get and yum – you can still drop to the command line and use the existing tools, but Packagekit has a pkcon tool (uses PolicyKit for auth) that lets you use the DBUS methods in an abstract way, that can be used on any distro. So it’s not exclusive with the other text tools, but you probably don’t need to drop to the native tools unless you are doing something really l33t.

    2) The point about user interaction is that it sucks. I know debian can ask questions – I did a few months of research before I started PackageKit – my point is that it _shouldn’t_ ask questions. You can make dpkg not ask questions my passing it specific flags, so the package still installs, and just tell the user after the transaction after the package has completed that a default was chosen and they might like to change it if they can be bothered. Also, another point – looking at Debian packages, the questions that were being asked were just insane. I couldn’t find a single questions that I thought “Hmm, that should block the transaction” – because that’s what the questions do – they block at the point of asking. That means an admin installing 400 computers would have to go round and click “ok” 400 times. That’s not cool at all.
    The real point is – underlying systems _can_ operate in “choose something sensible” mode and blocking the transactions crushes some of the main use cases like unattended updates when the PC is idle. I don’t hate dpkg at all, I just think it needs shoehorning into a “I don’t care what libc is” world.

    3) I think you misunderstand what PackageKit transactions are. If you look at http://www.packagekit.org/pk-reference.html#introduction-ideas-transactions you’ll see that it’s quite easy to do licence and EULA prompts, but they have to be done in a structured way, rather than just allowing a package to block and wait for input. Say if you queued an install of vmware, then queued an system update, then walked away for everything to download? Using the blocking, the single package would download, and be waiting for you to click “I agree” when you returned. The non-blocking way would be download vmware, download and install updates, and then ask the user to click “I agree” — much better.

    Feel free to email me if you have any suggestions — or better — email the mailing list and we can discuss there. Thanks.

  3. As a user I want my packages to just install without bothering me. PackageKit aims to do things the sane way from a user perspective not to build up as a unifying superset of all features in all package managers. PackageKit will compete with the other package managers on its usability vs. their more extensive power. And my odds are on packageKit to win.

  4. The only package format (I know of) that will accept input from stdin is deb. It is a pretty dumb idea actually and should be handled through debconf.

    The only reason it still does that is simply because no one has went throught the trouble and long flamewars to change the debian policy. Several DDs who’ve discussed this problem agree with Hughsie that package management should be silent thought.

    I’ll agree with you on your view of packagekit, but what debian allows packagers to do is fundamentally stupid. Period.

  5. I like this idea, because atm, if the software you need isn’t in add/remove, here’s what happens: for an open-source project, you go to their website, and for downloads, you get the link to the source code. Thanks. To sweeten deal there’s the quickly-installable .dmg or a .exe.

    And for a non open-source project, at best they’ll give you a .tar.gz too or a MojoSetup .bin. All of these solutions, anyway, bypass the really awesome Add/Remove where a) The user can get find & install the software quickly, b) The user doesn’t have to care where does it install, and c) When he’s uninstalling it, it really goes away, and doesn’t ask you to do manual clean up after.

    So if this thing will allow distributors just to make 1 package, that’ll use the nice package management systems on the distros, that’ll be a great deal of help for them.

    (and no, sometimes you just can’t use a <6 month copy of software, and a lot of times it’s not even in the repositories)

  6. I’m with you on this one man. I’ve played with PackageKit on both Foresight and Fedora 9 and I’m unimpressed. The UI can’t hold a candle to what we have in Ubuntu (Synaptic, Add/Remove) so in that regard it is not “neutral”, but a step back for us. The caching system in PackageKit on Foresight is useless as well.

    It is also very noticeably designed by .rpm-types, which is where the “keep quiet and just install” mindset comes from (one of the fundamental differences in .deb vs .rpm). Unless some of these things get worked out I am in no rush to see PackageKit in Ubuntu as I see it, in its current state anyway, as a step back.

    Hopefully however posts like this will be seen as constructive so things can be improved, and not seen as attacks. I do agree that it is a very exciting idea, so long as it is implemented correctly.

  7. many times, debian packages ask totally esoteric questions.

    noone sane can love them. or then linux is just ugly professional stuff with nice colors ?


    packagekit wants to remove all the weird questions and try to be minimalist.

    People wants the computer to complete works. Not to struggle with them.

    packagekit is a frontend on top rpm and dpkg, not to remove yum, apt or whatever. but surely, an ubuntu distribution could choose to only show packagekit utilities.

  8. Some questions are relevant, like licenses (a well discussed topic already). Another example would be the question to restart sshd or not. Maybe not all that important for packageKit, but if you’re upgrading via ssh you better hope the default is no. But if that also means PK’s auto install security packages feature will leave unpatched services running.

    Are there any packages left that still ask questions at the Default level? It might make sense to find these guys to evaluate whether asking no questions ever is sensible for Debian / Ubuntu.

  9. I hope “to create a user friendly package handling abstraction layer that is independent of distro and package format” is not the goal.

    I would look for a goal like “help Linux workstation users keep their system updated and add new software, with a minimum of hassle” or something like that. Framed in terms of who benefits and what the benefit to them is.

    Personally I don’t care if my software updates UI is abstracted, or independent of distribution. I care whether it’s well-designed UI-wise and works, though.

    I would think distribution-independence is instrumental to the goal – makes it easier to collaborate on a joint project and integrate with GNOME – but, I don’t think it is the goal. It’s means not ends.

    I think “package handling” or “package management” is means not ends as well. I care about latest updates, and I care about installing new software, but I don’t care about packages for their own sake.
    There are other non-package ways updates and new software could be done. And packages drag in implementation baggage that I don’t need to see.

    If “package management” is the goal that implies I need to see all the details about packages, and I don’t. (There may be use-cases where I do, but I don’t think all of said use-cases are in scope for PackageKit.)

    And yeah, I realize it’s called PackageKit. Not ideal.

    Not every piece of software should do everything. For a lot of purposes, a command line app might even be the best UI design.

  10. Don’t discount “generate an error” as an appropriate means of programmatic flow. While it is less common in current practice, exception-based processing was previously quite common (e.g. PL/SQL, Ada), and has first-class support in common languages (C++, Java, Python, Ruby, etc.). While a given transaction might fail, there is no reason the code cannot capture the results of this failure to provide a useful interface to the user, and retry the transaction once the required information is complete.

    In the specific case of handling prompts generated by debconf, by maintainer scripts, or other similar handling, the containing program ought be able to collect the output, and appropriately generate a UI that allows the user to provide sufficient information that the transaction can be completed successfully on retry (although in the case of maintainer-script prompts, this is very difficult: another argument for debconf).

    That said, I think you have a telling point about the utility of such a unified package management tool having a consistent set of underlying semantics. If different package management tools at the distribution level have different semantics, hiding this through the use of a unified UI is more likely to cause confusion than to be successful. Without consistency on the meaning of any given action, any generated documentation for PackageKit is inherently dependent on the semantics for the backend user by the reader being the same as those for the author. This is especially difficult given that each package manager in current use has different states in which a package may be, including states used internally by the backends, and rarely exposed to end-users. When something goes wrong, these internal states are exposed, and a tool like PackageKit ceases to be able to sufficiently understand the system to handle the discrepancies (e.g. PackageKit won’t be able to do the right thing when one needs to run `dpkg –configure -a`).

    While this isn’t a regression from the majority of GUI tools available, most of which instruct the user to fall back to the underlying tools in the event of difficulties, the introduction of a tool like PackageKit provides an opportunity to establish a single meaningful set of semantics, both allowing the tool itself to resolve many difficulties, and allowing for collaboration between distributions to handle irregular cases, migration support on upgrades, etc.

  11. Hugsie is correct on the requirement for silentness. Keeping software updated is about internals of the computer and does not help the end user in his real world problems. It really does not produce any extra value for end user to have to click yes yes yes yes constantly.

    Plus, average joes do not understand the prompts (not even the simplest form) or their consequences anyways, or really care. Best example of this is those errors about broken SSL certificates when browsing. Considering that the user wants to get on the page, all 99.999% of the users press is YES no matter how grave warning you produce. The really only working solution to this would be to remove the prompt and simply block the access to these broken sites without any way to force the browser to start trusting the borken certificate. Then after a while the website owners would start fixing their utterly broken sites.

    Anyways, package updating should be pervasive. I really don’t even as more advanced user care at all what the updates are. The Ubuntu’s updates have gone some testing anyways, and contain only (backported) fixes with very little chances of bringing any problems. I grow tired clicking daily yes, not to mention seeing the popup spam and the spammy icon on my task tray. A little cron job does the job with a lot higher usability, and more reliably as well…

  12. About the silentness of upgrading, installing or removing packages:

    I agree that upgrading, installing and removing packages should be as much as possible silent. Reasons:

    (1) Richard Hughes’ point 2: an admin installing 400 computers would have to go round clicking “OK” 400 times.

    (2) If you install/update hundreds of packages and leave your computer unattended for an hour, you expect the packages to be installed/updated. The last thing you want is that only a few packages are installed because the nth package blocked because of an interactive prompt.

    Even though I very much agree that most forms of install/update prompts are completely unnecessary, I might understand that in some cases they are necessary.

    It would be nice to know however in advance which packages don’t (always) install, update silently. In an attempt to alleviate problem (2), the system then might install them (and their dependencies) first (and tell the user that the rest of the stuff will update automatically); or alternatively install them (and their dependants) last, installing as much packages as possible before blocking.

  13. Lots of people in this discussion are completely missing the point. Whether Debian packages should be allowed to require interactivity or not is moot: some do, and we have to live with that. If you want to “unify” package management, you have to deal with what is out there. Period.

  14. No mention of the horrible UI of package-kit.

    Too ‘low-level’ to replace add/remove for my mom.
    Too ‘high-level’ to replace synaptics.

    In its current shape, it serves _no one_.

    I think it should pretty much copy as much as add/remove’s interface as possible.

    The synaptics type tools, shouldn’t be ‘unified’ with some generic tool. It’s impossible. Pinning, forcing a version, etc. That’s all very distrobution specific.

    They should let the expert interface to the distrobution maintainers.

    Nothing wrong with making an add/remove type interface part of gnome off course. But just desktop-app, shown by name. (not by package-name).

  15. Nobody is bothering to think about the guy in a company who gets the task of making sure that the company’s product is installable on Linux.

    At the current state, he’ll either not care and give a NON user friendly tar.gz for download, or curse at each new package management system he has to learn.

    Or just tell his company to screw linux, it’s too complicated, and support costs are going to be huge!

  16. Hello I was doing some searching around the Internet after playing with PackageKit which seems to be the new default installer for Fedora 9. I like the critiques you have they seem legit and since the PackageKit developer seems to be paying attention to your blog I thought I would try to contribute.

    I like a lot of what I see as far as being able to go to the software projects home page with a simple click and the GUI looks nice.

    I love seeing what files will be written out or modified and the fact that you can go click inside of that box and save the list with a copy or paste for whatever reasons you feel you may need.

    The immediate usability issues I have are:

    – I have to tell it to refresh application lists, this should be default or a more readily identifiable option. I first went through a few sub-categories getting a ”Query produced no results” type of error before I started looking for an option to view software I knew should be there.

    – I found no way to select multiple software packages then say install and walk away. You have to sit there and click one package → Hit Install → Watch it download and install → select next package and repeat. I really hope I’m missing something here I do not have the time to install all of the packages I like to use one at a time after my initial install.

  17. I recently installed Fedora 9 and knew I would need to go thru the update process to get all the latest mods. I hate the whole update thing (in MS Windows, too), although necessary for now, so I’m very interested in a process that works and is easy and user-friendly.

    I did a default install, nothing fancy, and didn’t even know there was such a thing as “PackageKit” until I logged in and started to do my usual “yum” update. Before I could get yum going there was already another update process running, which turned out to be PackageKit.

    I gave PackageKit a chance since it was new and automatic, but quickly saw that I wasn’t getting much feedback and couldn’t turn it off even though I wanted to so I could go back to yum.

    My problem with the “out of the box” PackageKit is that I don’t know exactly what it’s doing and how far along it is. I’m used to seeing “here’s how much I’m going to download” and “here’s how much I’ve downloaded so far”. With PackageKit I get neither, so I don’t know whether to wait a few minutes for it or just go to bed and check it in the morning.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s