[packagekit] Semantic issues with GetDeps (and other interface functions)

Travis Willard travis at archlinux.org
Mon Sep 3 16:03:49 PDT 2007

On Mon, 3 Sep 2007 19:00:25 +0100
"Richard Hughes" <hughsient at gmail.com> wrote:

> On 03/09/07, Patryk Zawadzki <patrys at pld-linux.org> wrote:
> > On 9/2/07, Richard Hughes <hughsient at gmail.com> wrote:
> > > On 02/09/07, Tom Parker <palfrey at tevp.net> wrote:
> > > > 'k. I think I've got a better handle on the sort of dependancy
> > > > resolution we want here. I think a reasonable summary is
> > > >
> > > > * Pull in all "suggested" or "recommended" packages, as they
> > > > will help the user actually use the package they're asking to
> > > > install.
> >
> > Why not ask the user which of these he really needs? Especially as
> > there can be some mutually-exclusive packages in the suggested list.
> Then we try to do the sane thing. If the user has gnome installed by
> default and there is a choice of a gtk or qt backend then we choose
> the gtk backend. The average linux use doesn't know the differences
> between qt or gtk.
> > > > * Don't remove anything unless explicitly requested.
> >
> > What about "Obsoletes" matching a package name (not its "Provides")
> > at least in rpm?
> I guess obsoletes are okay, as this is what the packager actually
> wants. Might be good to add this to the spec.
> > > > * If we can't install a package *without* removing other
> > > > presume). Assume that this doesn't happen very often, and that
> > > > there's another way to install packages using the native
> > > > packaging system.
> > > Yes, good summary.
> >
> > Until the above two are decided upon, I can see PackageKit failing
> > on most operations for me.
> I'm possibly being a little harse here, but I don't think PK is
> targetted to power users like you. If you ask my firlfriend
> (non-techy) "just install openoffice" and a window comes up asking if
> she wants java, gtk or qt then we've lost, as she doesn't know what
> any of those mean. She just wants to install openoffice so she can use
> it.
> > There should also be some output-collecting service that can present
> > me with any output from the installation (some packages are only
> > usable once you read the installation output as not all things
> > can/should be automatic).
> No we don't want this. If software need to get the user to set stuff
> up, then this should be done on the first run of the software. e.g.
> service http start
> Error: you need to setup the httpd.conf file...
> At *install* time is not where configuration should be done.

Why not?  When you install your favourite web server, what's the harm
in a message saying "Set up your httpd.conf file"?  What if it provides
a default config, and so service http start doesn't give the user the
nice warning they need?

Besides that, saying "if software needs to be configured, software
needs to change" won't help, because we don't control upstream
software, and even if we provided a patch or somesuch, they might not
accept it.

I see no harm in log messages, so long as it's done in a way that
doesn't pester the user.


More information about the PackageKit mailing list