Written July 8, 2008 in fedora, linux

This is not a complete man page:

PKCON(1)                                                              PKCON(1)

NAME
       pkcon - PackageKit console client

SYNOPSIS
       pkcon [ search ] [ debug install ] [ remove ]

DESCRIPTION
       This manual page documents briefly the pkcon command.

       pkcon is the command line client for PackageKit.

SEE ALSO
       pkmon (1).

       The programs are documented fully on http://www.packagekit.org.

AUTHOR
       This manual page was written by Richard Hughes .

                                  22 May 2008                         PKCON(1)

Man pages are for when a user is offline and does not have access to the internets. Telling them to refer to the internets to know how to use pkcon to administer their system is useless.

I’m starting to agree with jwz about my frustration with linux: “Your mission critical business platform is my summer project” does not make for a stable operating system.

Update: I spent some time in #packagekit on freenode. The general opinion I got from one of the dev team members was that:

  • Packagekit shouldn’t need documentation because it should be so easy to use that there’s no question about what to do with it.
  • Installing i386 arch packages along side of x86_64 bit packages is an “Advanced” feature that sysadmins should do and should not be doable from the gui or the pkcon command line tool. (Even though the GUI will currently allow you to TRY to install an i386 pacakge on an x86_64 machine, but will tell you that it’s already installed and fail with no other explanation. Especially because there’s no documentation.) One patently userland application that still requires i386 pacakges: Flash plugin for Firefox.
  • Documentation is a userland activity that programmers shouldn’t be responsible for. They’re spending most of their free coding time working on the project.
  • The search and filtering options completely suck ass, but we have pretty shiny icons!
  • Where else are you going to test software besides the real world? Um, that’s what ‘rawhide’ is for. If your target is nontechnical users, please make sure that it’s at least usable for technical people and for people who work along with nontechnical users and know what their needs are first.

Just unreal. So there we have it, folks: PacakgeKit sucks. Thankfully, there are no plans to remove yum from Fedora that I know of… but I feel bad for any users that are stuck using this pile of crap. It’s ridiculous that the Fedora core team has allowed this turd into the main release.

4 comments on ' Dear Packagecon Dev Team, '

  1. Agreed, the man page is crap. If you also consult the many, many pages of yelp documentation I’m sure you’ll be able to work out how packagekit works. There’s an online version here: http://www.packagekit.org/gtk-doc/ and you should have an installed version too.

    I’m also not sure who you talked to in the #PackageKit channel, but they are wrong. PackageKit *is* hard to use on the command line, and does need more docs. Docs are hard to write, and I don’t have much experience with sgml and manfiles. I’ll gladly give you commit access if you can help us with them as I’m sure they just take a bit of time.

    The x64 and i368 problems are due to bugs in the yumBackend.py code. I don’t yet have a 64 bit machine to test PackageKit on, and so I rely on people like you submitting bug reports and helping me test fixes. There’s no logic preventing you from installing ~arch packages, there are just a couple of bugs that need fixing.

    If you also install gnome-packagekit, please also see the help there; there’s lots of it, and I wrote most of it. Both files are also translated into many, many languages.

    As for the search, I’ve spent the last 3 days optimising yum so the search results appear near instantly. I’m still not sure on how to fix the filter menu, but I’m talking with some user interaction people at Red Hat and we think we can remove some of them and make the menu a bit more sane. I know it’s not ideal, and we are working on it.

    As for testing, there’s a new 0.2.3 version in fedora updates-testing, and has been there for a few days. I also posted to the fedora-devel mailing list just yesterday asking for feedback about the new packages. I don’t think you’ve done much research at all.

    I find it sad that you think PackageKit sucks, especially when you didn’t even email me or open any bugs to discuss different issues. I also find it quite upsetting you calling it a “pile of crap” as quite a few of us have worked very hard getting PackageKit to where it is now in this short space of time. Basically, you’ve insulted my hard work. Thanks for that.

    Many thanks.

    Richard Hughes (PackageKit maintainer)

  2. Well, pk doesn’t actually do any package handling itself, it delegates everything to whatever the packaging system is for the distro. On fedora it’s yum. On debian its apt-get.

    If you don’t like how pkcon plays with wrt features, etc, I’d suggest you ‘yum remove packagekit’ and be done with it.

      Written by Seth Vidal on July 08, 2008 at 3:08pm

  3. Richard, I’d be happy to provide some UI pointers. I’ll install the version from devel and see if it works better for me.

    I’ve sent via email the chat log from earlier today, and will also send this comment in an email so that I’m sure you’ll be in the loop.

    Over the past few years, I’ve made specific choices about what experiences I let into my brain and what computer experiences and influences I’ve put myself through. I bought an Apple laptop for home/consulting use and strived to internalize the communication methods and standards that Apple uses in it’s OS to make things ‘easy’ for users. This has also led to a lesson in how Apple and other successful consumer software companies (and open source projects) communicate expectations to their users.

    What we have here — my opinion that it sucks, and your opinion that you’ve put a large amount of work into it and that it *doesn’t* suck if I’d just think about it the way you do — is a breakdown in communication. It’s in a few specific places, but all of them can be managed with a little effort.

    First, the Fedora Project has chosen gpk-application for it’s default package management. Even though Fedora is a “bleeding edge” distro whose goal is to get user uptake of the newest applications, various prominent people are installing Fedora for their home users. Didn’t Linus Torvalds just install FC9 for his wife? This would place the onus on developers who want to include their work in FC to make sure it’s ready for primetime so that they can get the biggest boost from Fedora’s efforts.

    Second, in my opinion the gpk-application that ships by default in FC9 is not ready for userland because of some key user problems. You will alienate grandma, mom (or Mrs. Torvalds) because he or she can’t install the software they need, even though they can see it. They just get an error that they can’t work around.

    Third, you alienate the experienced user because the first place a sysadmin will usually turn is the command line programs and man page documentation. There is very little of this documentation, and what there is simply refers you to the website — where the yelp documentation is not featured at all as far as I can find on the “How do I use packagekit?” page on the website.

    Managing communications is essential to the success of a project or company. Thanks to that second communication, grandma or mom or Mrs. Torvalds will go to her sewing circle and say that linux isn’t user-friendly and she’s just frustrated. And son, who happens to be a sysadmin in a big company, chooses to have nothing to do with packagekit from then on because his first use of it was negative.

    I’d be delighted to provide what suggestions I can, especially in the UI area. I’m not much of a coder when we get out of procedural scripting languages. But like I said, I’ve dumbed myself down on purpose in order to help myself communicate with my users… and there may be some value in that.

    I’ll install the dev versions and join the devel mailing list tomorrow.

Trackbacks/Pingbacks

Leave a comment

name (req'd)

email (req'd)

website