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 www.packagekit.org 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
InstallProvides(fedora)=audio/QCELP

# Just for Fedora 9, install two development files
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# On any distro, install the package with this file
InstallFiles=/usr/bin/fontinst

# For each architecture on Fedora 8, install one of the two different compat files
InstallFiles(fedora-8-i686)=/usr/lib/pango/1.6.0/modules/pango-arabic-fc.so
InstallFiles(fedora-8-x64)=/usr/lib64/pango/1.6.0/modules/pango-arabic-fc.so

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
InstallPackages(fedora-9)=glib2-devel;PolicyKit-gnome-devel

# Rawhide is fedora 9.90
InstallPackages(fedora-9.90)=glib2-devel;PolicyKit-gnome-devel;unique-devel

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?

11 responses to “PackageKit bundles?”

  1. Alexander Jones

    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. Vincent

    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. Vincent

    Darn it, stupid OpenID on wordpress… Is it possible to remove my last name from that post? :)

  4. Hmm

    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!

  5. davidz

    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.

  6. oliver

    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).

  7. Vincent

    Thanks for removing the last name Richard. And I like the name catalog :)

Bad Behavior has blocked 2769 access attempts in the last 7 days.