Fedora 9 Beta, PackageKit and system-config-printer

Jeremy Katz katzj at redhat.com
Mon Mar 17 19:52:29 UTC 2008


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




More information about the fedora-devel-list mailing list