Bundle is no more. The new name is catalog.

Just that’s the plan. Something like: InstallBuildDepends(debian)=packagekit

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

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.

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.

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,

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!

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.