PackageKit bundles?

There’s one use case that I’m very interested in, and that is getting new users with the correct environment to build and start hacking on software or using other software tools. For instance, on in the FAQ section, we can have a link to install build files to start hacking on PackageKit.

Now, this .bundle file is handled by gpk-install-bundle that parses this file and causes the appropriate packages to be installed if they are not already installed. This rocks as we can get GTK+, Xorg hackers up to speed with the minimum of fuss and confusion. It also lets people put links on webpages to “install all the stuff you need” when writing a “how to use a scanner in GIMP” howto.

So, what does a .bundle file look like?

[PackageKit Bundle]

# Just a package on all versions of fedora that can provide the dependency.
# If there are multiple packages then the user will be asked to choose

# Just for Fedora 9, install two development files

# On any distro, install the package with this file

# For each architecture on Fedora 8, install one of the two different compat files

You’ll notice the distro-id in between the ()’s – this lets a packager fine tune the package name, where for instance in Debian the package is called policykit and Fedora PolicyKit. You can specify a granularity of distribution, distribution-version or distribution-version-architecture – PackageKit will process all the entries that apply. It’s of course better to not specify a () if possible, as this lets the file work on as many distributions as possible out of the box.

There’s also no version checking – intentionally – the distro should be specified and have the correct data. If there’s an optional package not in earlier versions then you can do something like this:

[PackageKit Bundle]

# Fedora 9 does not have Unique

# Rawhide is fedora 9.90

There’s also no description of the bundle that needs translating and verifying – they are just lists of packages, files and provides that might be useful. All the translations come from the distributions metadata, and it’s up to the user to verify the package lists that are asked to be installed, so there are no signing or trust issues.

Note: this isn’t designed to replace one click install, it just does something that is similar in a different way.

Comments? Suggestions?

Published by


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.

11 thoughts on “PackageKit bundles?”

  1. If you’re gonna do this, don’t call it a bundle. Call it something that indicates more that it is actually “Package Installation Instructions”.

    A bundle sounds as if the software is coming with the file.

  2. Perhaps it’d be an idea to allow the provider of the bundle to specify which distributions are explicitly supported or which aren’t yet.

    For example, if the file specifies some specific packages for Fedora, then there’s a risk that it won’t work on Xubuntu because its dependencies haven’t been defined. In such a case, the bundle provider might want to specify that it will work on Xubuntu *without* those additional dependencies.

    However, when Xubuntu’s repositories for example don’t provide such a package, the bundle provider could specify that Xubuntu is not supported.

    Or perhaps it would even be possible to link to the required package on a third-party server so PackageKit could provide the user with the option to install the package from that server (with a warning of course) if the file still exists there.

  3. This is an excellent goal, but isn’t this subverting the package management system of the distro?

    Maybe this seems like a good idea to you because of your recent experience with packagekit itself, which is inherently a cross-distribution piece of software: you have unusually high insight into packaging, naming, dependencies etc. for multiple distros. I think this may not be typical.

    I can forsee wanting to hack on some piece of software on fedora where the upstream devs all use ubuntu, and so the bundle will not work and it will be very frustrating. I imagine it may also be a never ending task for the fedora (or whoever) packagers to keep a part of their packaging meta data in sync with ~6,000 upstream packages.

    Related: have you thought about plugin development? PackageKit already can install existing plugins, and with this your allowing folks to hack on the main program, but maybe some where in between there is hacking on new plugins? It would be great to have some introductory way to get started with a project by having the necessary dev packages installed (which may be less than for the whole program) and a skeleton plugin directory populated.

    Great direction, thanks!

  4. @Vincent:

    Yes, we should probbaly add a way to say “this isn’t going to work” for instance installing PolicyKit on breezy. I’m not sure if that means falling back to “sorry dave” or falling back to a common action. I’ve also removed your last name on you blog as requested,

  5. @Hmm:

    I expect the bundle file to be shipped in the project git or svn tree – then contributors can just add the needed bits for the distro upstream. Also, don’t get too worried about differences, 99% of the time the distro chooses the same name for an application – it’s the devel and debuginfo’s that get more interesting – and it’ll be the contributors or packagers that are aware of the differences.

    Also, PK supports plugin installing and removing, so it would make sense to add a “create your own plugin” link too. You can create and ship as many .bundle files as you like in your application – if you just “open” the bundle file then all the needed actions are done.

  6. Please stop calling it bundle; typically people associate things like OS X AppFolders with that thing. Call it what it is, e.g. Software Installation Instructions or, gosh, maybe 1-click-something.

    I don’t think it’s useful to say “this is only for installing development tools”; we don’t want 42 different formats (one for “installing development tools”; one for “installing music players”); try to generalize as far as possible.

    Please use XML install. It’s 2008 and the eXtensible aspect of XML is pretty useful here. For example, it trivially allows you to add things like signatures as well as extending any node in the description tree.

    Should also contain instructions to enable 3rd party repos a’la Livna; see my earlier mail to the packagekit list for details on how to do that.

    Also, FYI, Rawhide is sometimes x.91, x.92… yes, this is typically used for test releases but these are just snapshots of Rawhide. Also please include examples of how to do this for the RHEL and CentOS stuff; e.g. 5.0, 5.1, 5.2 and so forth.

  7. Just out of curiosity: doesn’t this solve a similar problem as “apt-get build-dep ” on Debian-likes (i.e. it installs all packages necessary for building the package itself)?
    If so, maybe both mechanisms could be integrated somehow (like automatically generating stanzas for Debian-like systems from their build-deps).

  8. @oliver:

    Just that’s the plan. Something like: Install´╗┐BuildDepends(debian)=packagekit

    But we need new API for that. That’s 0.3.x timescale.

Comments are closed.