GNOME Bugzilla – Bug 603757
Do not hardcode names of packages in code
Last modified: 2011-05-22 18:32:26 UTC
The new PackageKit support in file-roller is quite a neat feature. However, I'm a bit worried that the package names are hard-coded, and I can imagine that not all distros share the same package names. I'm not sure what's the right fix for this, and this is actually an issue that all apps integrating with PK will have, so cc'ing Richard to get his input.
Here's what I was told when I had the same problem in aisleriot: http://lists.freedesktop.org/archives/packagekit/2009-January/004267.html (I'm not really happy with this solution though.)
Ohh, it's totally intentional the names are hardcoded, in fact it's the best way. Let me explain. Distro v1.0 calls the package libdave Distro v2.0 calls the package libbave-2 (due to using the trademarked "dave" term) In the v1.0 version of the product it is decided to backport libbave-2 (and call it libbave) and obsolete libdave. This is done totally to the distros timescale, and the distro is free to call the package what it likes. The only person who knows what the package is going to be called at a specific point is the distro. The distro is an a unique position to patch other applications that require the change, and push them all as one changeset. Relying on searching for a installed package name is much slower, and doesn't work if the distro moves things around, like debian not using libexec for certain things. Trying to include all package names for n different distros, with m different versions isn't going to be fun for upstream at all. Push this to the distros. Arguing about package names is what distros do best. If upstream chooses a good default name (e.g. openoffice-writer), then it's up to the distros to patch this if they changed the package name to something else, e.g. "openoffice.org-2.0-writer-base" Anyway, thanks for the cc, and let the discussion commence. ;-)
Richard: oh, I'm not proposing to search. But at least hard-coding things in one header file would make things easier, indeed. As downstream, what I would love to have is a small file that I put in, say, /usr/share/PackageKit and that would do the match between my package names and the names file-roller uses. And the match would be done in PackageKit itself (this would obviously have to be done on a per-caller basis, so this implies passing an id unique to the caller to InstallPackageNames). So in the end, I would only have to create /usr/share/PackageKit/matches/org.gnome.file-roller.match which would contain [Package Matches] zip=MyTotallyCrazyName tar=tar-experimental # all names not mentioned there will directly be used unchanged (hrm, sorry for abusing the bug for what is obviously a PackageKit discussion)
It's now possible to specify different package names using a configuration file (data/packages.match).
Created attachment 188331 [details] [review] Fix implementation and use of the alternative package name lookup Since this bug is still open... I don't think the package name lookup logic for packages.match quite works currently. Or I'm going insane :(. Example: ======== 1. Uninstall all packages providing, say, RAR support (p7zip*, {un,}rar). 2. Modify fr-command-rar.c's PACKAGES to ask for the package "no-such-package", where no such package name is provided by your distro. 3. Modify data/packages.match to add: no-such-package=hello where hello is a package provided by your distro. 4. make && sudo make install file roller 5. Open a RAR file (there is one attached to bug #646562). 6. When told there is no RAR support installed, let PackageKit search for packages. Expected results: ================= The hello package is installed, possibly after a password prompt. Actual results: =============== Error message saying no-such-package can be installed. If you can reproduce, please consider the attached patch.
Iain, I've pushed your patch to master now, thank you.