On Mon, 2008-03-17 at 12:11 +0000, Richard Hughes wrote: > On Sun, 2008-03-16 at 21:34 -0400, Jeremy Katz wrote: > > The difference between pk-install-file and pk-install-package (or the > > non-existent pk-install-by-provides-name) is pretty arbitrary and not > > necessarily something that a user is going to know. > > Sure, I'm guessing users won't be using these directly, applications or > desktop launchers will. And we do need to split these as some packagekit > backends won't support resolving or installing a filename and some will. > We just can't accept free text input into the backends else there's no > abstraction whatsoever. The fact that the backends may have different capabilities doesn't mean you need to expose those details to the world with the frontends. There should be _one_ "install a new package by name" which can take files, package names, provides names, $whatever_other_crack_some_other_backend_supports. And then the frontend code just says "does this backend support this method? no, okay, keep going". > > And there's no need for alternatives, because supporting two packaging > > UIs is insane. > > We really don't have that kind of resources. Instead, > > we're going to actually *make* decisions and choose. > > There's about 20 lines of C to do this, most of the stuff is abstract. > See > http://gitweb.freedesktop.org/?p=users/hughsient/gnome-packagekit.git;a=blob;hb=HEAD;f=src/pk-install-file.c for how easy it is to do this with libpackagekit. Ermm, I don't think you got my point. Or I didn't get yours. Alternatives for /usr/bin/system-install-packages just between pk-install-file and pk-install-application can't work because there's no way to choose between the two at a system level. And we're not going to play that game between PackageKit and pirut because see above about resources. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
