On Mon, 2008-03-17 at 16:53 +0000, Richard Hughes wrote: > On Mon, 2008-03-17 at 11:40 -0400, Jeremy Katz wrote: > > 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". > > That's just not portable. I'm not sure "okay, keep going" would look > like as an API call. > > If we are going to do "give me the package that provides XXXX" then it's > a new method that should be implemented separately, not just overloading > the generic Resolve() or InstallPackage() methods. You're still missing my point. The fact that all of these are handled with different methods to the backend _doesn't_ mean that the user should need to know the difference. I don't care if there are 5 or 100 different things in the backends that the frontend knows about -- that's a lot better than the user having to decide which of 5 or 100 commands to run[1]. The user wants to run "install the package which meets this criteria" -- how the criteria matches to an actual package shouldn't be a detail they're worried about Jeremy [1] Unless you're git ;-) -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
