GNOME PackageKit updates

A few nice things have been happening lately. The first is the re-versioning of 0.4.4 to 2.27.1, so that we can stick to GNOME release versions and the promise of release freezes. This should make it a bit easier for distributors, and will make the transition to gnome.org a little bit easier.

We’ve also been doing some tinkering around the edges to make things work better, hopefully without getting in the way. This is shown quite nicely from the following UI from the new update viewer.

Saving you money every day of the week...
Saving you money every day of the week...

And, thanks to Daniel Nicoletti, PackageKit now understands media requests, so the backends can request the user do something with physical media. This is still using the non-blocking logic we’ve always been using, so if we’re using multiple disks then the content has to be copied off each one in turn before the transaction, rather then installing direct from the media. Trust me, it’s better this way.

New media change dialog
New media change dialog

We’ve also been removing some dead code (libsexy, libglade, etc), and tidying up the existing objects, so hopefully 2.27.2 can be released in a few weeks. Comments, as always, welcomed.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

33 thoughts on “GNOME PackageKit updates”

  1. Instead of a dialog, show it somewhere in the main window?

    It’s anoying to take action, and then the computer asks ‘are you sure, because XYZ?’. The user has made a decision don’t question it, but provide all information needed before asking the user. At least in this case ;)

    Either the user already knows and is pestered with an extra dialog or the use didn’t know but have to reevaluate the choice again.

    For consistency with the rest of the desktop – show a cluebar in the top of the treeview if you are on a possible per byte charge. (Maybe usefull in other cases)

    As usual just critique and no productive work (patches).

  2. Frej: I totally agree. I’m waiting for the cluebar widget to be added to GTK in this cycle. When it gets added, yell, and I’ll convert over.

  3. If the user’s session is going to automatically mount the DVD when it is inserted then the media change dialog does not need a Continue button. The dialog could just disappear once the correct disc is inserted.

  4. Looks great!

    Regarding the wireless broadband thing, is it also possible to do this check before any metadata is downloaded?

    For example, with the yum backend on Fedora there is over 3MB of metadata at a minimum to be downloaded every time just for the ‘updates’ repo (ignoring other repositories). If the file lists or other data need to be pulled in during dependency resolution, up to 20MB can be downloaded before even showing the “updates available” message. If this wasn’t bad enough, when yum gets the repomd.xml file from an up-to-date (or partially so) mirror, it can repeatedly download the metadata from stale mirrors only to find it doesn’t match the hash, trying again (and again, etc).

    I have no idea if this is a problem with just yum, rpm or Fedora or if all update systems have this problem. It’s obviously not a problem with PK though, so please don’t feel like I’m blaming you for this :).

    Perhaps a solution to this deeper problem would be to generate a compressed and sorted dependency graph/tree so that only a relatively small file is required to see which packages need to be pulled in, which rpm could easily verify after downloading the packages and if necessary fall back on the extended metadata. Obviously there would be some finer details to work out, so I’m not sure if this would be possible or not.

    codebeard.

  5. @Sam Morris: That’s the big plan. When we send the MediaChangeRequired, we actually send the storage type, the volume id (label) and the media label. I’ve not coded that bit up yet, but it should be pretty easy. Volunteers welcome.

  6. I think that “trust me, it’s better this way” remark was tongue in cheek, right?

    *watches the free bytes number in his partitions mournfully*

    FWIW I like the screenshots and think that the popup dialog is appropriate in these circumstances. I reserve the right to change my opinion once I’ve actually experienced it popping up on me, say, five times. ;)

  7. I would hope the UI would have a checkbox or some other mechanism for remembering the user preference?

    Some of us have mobile broadband with unlimited access plans. Being asked once is thoughtful. Being asked every time would be annoying.

  8. commit 513d92291546723537d3a1451846f6515348e672
    Author: Richard Hughes
    Date: Tue Apr 14 17:38:13 2009 +0100

    trivial: add a do-not-show-again checkbox on the mobile broadband nag screen

  9. I love the attention to detail that you guys are putting into this.
    I wish more projects would provide this kind of feedback to the user.
    Just be careful to not present the messages using too many modal dialogs ;)
    Keep up with the good work!

  10. Looks very cool.

    One detail though. The text in the dialog says it may be expensive to download.

    The following (studpid) question might be:
    WHY is it expensive?

    Is it because he has to pay his softwaredistributor for updates when retrieving via wireless? Is it because it takes more power out of the power outlet?

    A few words might clarify this!

  11. I take it you’re just looking at the type of connection to determine whether it costs money.

    A better idea would be to have UI in Network Manager when setting up connections that lets you specify whether to take connectivity for granted or not. That way, people with HSPA-802.11 bridges can be safe too. Store it in the connection metadata somehow, or propose a standard.

  12. Wouldn’t “mobile broadband” be a better term than “wireless broadband”? Wireless broadband might be interpreted as Wifi by some.

  13. I find these 3 steps info In your blog in http://blogs.gnome.org/hughsie/2008/11/15/pkcon-list-install-foopackage-list/ very interesting.

    ” 1.

    pkcon list-create hughsie-laptop-f9.package-list

    2.

    pkcon list-diff hughsie-laptop-f9.package-list

    3.

    pkcon list-install hughsie-laptop-f9.package-list”

    Have you come up with a way to replace step 3 with “create a service pack of the difference” such that step 3 could be..

    “pkgenpack list-diff=text_file_containing_diff -l=package_list_name -o=service_pack”

    Thanks in advanced for this. :-)

  14. Sorry to play the bad guy once again. :oops:

    Do we really need all this kind of NetworkManager integration? This makes gnome-package unusable for people who prefer to use something else (wicd, wifiradar, etc.)

    Instead of introducing all kinds of funky features you should focus on fixing bugs. Looking at my Bugzilla frontpage I see eight bugs I opened of which four are filed against gnome-packagekit. None of them is assigned, 3 didn’t get any attention from you at all. I also have a backtraces of a crashing gpk-application here, but I don’t dare to submit it as you don’t seem to care anyway and showed an amazing amount of ignorance previously in bug 485846.

  15. @Christoph:

    Yes, we need NetworkManager integration. But, if you don’t want to use it, you don’t have to. If you don’t start NetworkManager, PackageKit falls back to legacy unix code just fine.

    With regard to fixing and triaging bugs, it’s called open source for a reason. It’s a lot easier to fix a bug with help, and patches go a long way. Filing a bug is 10% of the solution, as developers are rushed off our feet at the moment.

  16. @Andre:
    I do accept decisions, but I cannot accept Richard’s behavior:

    Richard says he had many complainants, but he wasn’t able (or willing) to show a single one. On the other hand I showed some that support my POV. There are even more in Lauchpad (thanks Richard for mentioning LP).
    Richard also said that he doesn’t have the time to search through bug reports, but obviously he has enough time to implement fancy icons, useless dialogs and other stuff that nobody really needs. Next time Richard asks me for help, I will most likely reply I don’t have time ether.
    Richard did not reply to any of my arguments.

    Besides that: There is no code missing, it was already there, but has been removed. Please read the bug report again.

    Sorry if my reply and my comments in the bug report sound harsh, but to me this is the most arrogant decision from a developer I have seen in 10 years of using Linux. I know I’m not alone with my perception, please take a look at the list of people cc’ed to the bug(s).

  17. @Richard:
    Thanks for your reply. Unfortunately I didn’t see it before I submitted my previous comment. So please let my reply to your arguments:

    It’s a lot easier to fix a bug with help, and patches go a long way.

    I asked you what you need to debug the problem, no reply. Even if I provided the additional information you asked me for I got no reply ether. You are not even replying to an RFE where I already attached the necessary patch.

    If you tell me what info you need to debug the problems, I’ll be happy to provide it.

  18. @Richard: Less arrogance please. ;) Remember, when I’m submitting bugs or patches, when I report my laptop’s keyboard events or when I’m defending you on devel-list, I’m doing all of this in my free time.

  19. The main problem with guys from the desktop teams is always, that writing code and new features makes just more fun rather fixing the own already written ugly code so remove existing bugs. With respect to the maintainer of packagekit, but he unluckily doesn’t seem to be an exception.

  20. Sorry Cristoph but you’re just crying because your bug report #485846 was closed with a wontfix, and it was the right thing. Moreover Richard didn’t show any arrogance in the bug (no, I don’t consider “it makes me laugh” as arrogant).

    That bug is just plain stupid (sorry for the word)

  21. When you’re talking about 2.27 reversioning you’re referring only to the Gnome GUI, right?
    It wouldn’t make much sense to me to reversion also PackageKit, it’s used also by KDE!

  22. @Vide:
    No, I’m not crying because the bug was closed. As I stated previously I do accept decisions very well. But if Richard says he has “loads of bugzillas” he should be able to show at least a single one. There were more then ten people complaining about the missing slider and nobody about the absolute sliders, but Richard doesn’t care. To me not listening to users and not replying to questions is arrogant, especially when somebody claims to know “what people wanted” (TM).

    Time is no argument ether, because obviously Richards spends enough time on things that nobody really needs. Nobody expects a package manager to think for him but to do package management. Currently gnome-packagekit lacks very basic package management functions, but – hey! – it has fancy icons and warning dialogs.

    And the criticism that I was only filing bugs is IMHO unjustified, because I do everything to debug problems, submit patches etc. Please take a look at the gnome-packagekit and gnome-power-manger bugs in Red Hat’s bugzilla.

    BTW: After my last comments some bugs were changed from NEW to ASSIGNED. I feel sorry that it seems to need such strong words to make this happen.

  23. Even though I’m in the U.S. and have never encountered a metered Internet connection, I like this change. It shows a level of polish and robustness that will give me a better feeling about the rest of the app. A few comments:

    1) I think in the long run this should be handled lower down in the stack
    2) The one post that suggested Network Manager handle this had some negative feedback along the lines with extra dependencies. There is no reason this has to be true. The lower level stack piece could be outside Network Manager and both could conditionally use this third piece.
    3) Long long term it would be nice to see a web service that queries a community built database of net blocks that charge
    4) Long long long term is would be nice to have a networking spec for querying this information directly from the provider via DNS or broadcast. But that would be 5+ year type stuff. It’s important because a lot of ISPs are looking at putting caps on bandwith so even though it’s low cost it isn’t free.

  24. Interesting idea. Regarding

    “trivial: add a do-not-show-again checkbox on the mobile broadband nag screen”

    I take it wireless means “mobile broadband” and not wifi connections. Perhaps the checkbox should be keyed to the particular connection? So you can “do not show this again for this network”?

  25. For the love of all that is good….

    Please RESET the “search type” to “Search by name” when the Add/Remove is restarted!!!!

    I don’t know how many times that I am searching for a package/etc only to find out that nothing is showing up because I had set it to “Search by Description” or “Search by Filename” and forgot about it.

    Resetting it to “Search by name” after Add/Remove is restarted is a workaround because the gui is not …how can i say… user friendly.

    It should SCREAM to the user what/how he is searching. Maybe:

    Search by [x] Name [] Description [] FileName
    ______________________________________
    |Somepackagename |
    |______________________________________|

Comments are closed.