[packagekit] Properties and Supported

[Richard Hughes]

On Fri, 2008-02-15 at 20:53 +0100, Sebastian Heinlein wrote:
> Am Freitag, den 15.02.2008, 18:35 +0000 schrieb Richard Hughes:
> > On Fri, 2008-02-15 at 18:07 +0100, Sebastian Heinlein wrote:
> > > Am Freitag, den 15.02.2008, 15:00 +0000 schrieb Richard Hughes:
> > > > On Fri, 2008-02-15 at 08:57 +0100, Sebastian Heinlein wrote:
> > > > > have you already thought about implementing a common GetProperty method
> > > > > in PackageKit? There are always special needs by distributions, e.g.
> > > > > support life time of a package.
> > > > 
> > > > I think a general getter is too loose in API definition. What parameters
> > > > do you want to get at per-package?
> > > 
> > > I would like to have origin
> > 
> > What's origin?
> 
> The label or url of the repository the package comes from.

Ahh, that's covered by the repo_id which is typically appended as a
suffix to the data field in a package_id. Why is the full URL useful in
the UI? Surly the repository name is most useful?

> > > support
> > 
> > Which is?
> 
> You can either buy support for this piece of software from the
> distributor or the distributor provides security updates for it. Since
> this information should be somehow in the description view of the
> frontend we need more than only a filter. See below.

Is supported a boolean? If so we can add it to GetDescription trivially.

> > Like group?
> Traditionally you get a long list of package names in the update viewer.
> The idea is to look if there is an application is provided by the
> package (it includes a .desktop file). If so the application name will
> be displayed to the user. If the package provides more applications all
> will be listed, e.g. gnome-games.

Sure, but that's a fronend thing, not a package thing. All the rummaging
around in desktop files has to be done offline, not at search or
GetUpdates time. PkExtra should have all the needed meta-data for
desktop files.

> If a package does not include an application we would look at other
> packages of the same source package.

So you mean if you need to update glibc then you only show that, rather
than glibc-common, glibc-data, glibc-devel? If so, then that sounds like
a client or server side filter.

> If there is no application inside the source package at all, we will
> only show the section of the package. E.g. the x-server does not provide
> an application, so most likely the user is not familiar with it. It
> seems to be enough to only show that there are 4 updates in the x11
> section, which would be shown as "Graphical User Interface" to the user.

Couldn't we just re-use the group enum of the package when we put them
into update groups? Having two types of group enum doesn't seem like a
good idea to me.

> > > tags
> > 
> > Which are?
> 
> In Debian we have got debtags. See http://debtags.alioth.debian.org/
> 
> Here are the tags of Nautilus:
> 
> Tag: implemented-in::c, interface::x11, role::program, scope::utility,
> suite::gnome, uitoolkit::gtk, use::browsing, use::organizing,
> works-with::file, x11::application
> 
> Or Eclipse:
> 
> Tag: devel::ide, devel::lang:java, implemented-in::java, interface::x11,
> role::program, suite::eclipse, use::editing,
> works-with::software:source, x11::application

Sure, but this is very apt-specific right? I'm not sure such
apt-specific tags belongs in a common API. How could they be useful in a
GUI?

> > > , supported mime-types and codecs.
> > 
> > Why do you need this in the UI?
> 
> If you click on a file for which no handler is installed I would like to
> get a list of available software that can open that specific file.
> Advanced use is the codec installation.

It's a cool use case, but I think we need to talk about the use cases
(and what to have per-session or per-system, and what to cache or query.
Could you start another thread and we can work out a way we can do this
in an abstract and distro-neutral way. I think I'm erring of PkExtra and
desktop files again, we just need to slurp this (and other data) into a
sqlite table and then query this offline.

> As a side node: there is even an addition to command-not-found. If you
> type a command into the terminal which is not installed you will get the
> name of the package that you have to install.

Sure. How does this work? I guess this is in the scope of PackageKit
also.

> > > Why did you decide to hardcode the list of groups? Should the frontends
> > > not be able to deal with flexible groups/sections?
> > 
> > Well, the backend can choose the group enums. We can't have a free
> > choice as the fronend has to be able to localise the selection as the
> > daemon runs in the C locale.
> 
> You could change the gettext domain in the frontend.

We do.

> E.g. the frontend uses gnome-packagekit a call of gettext would look
> like this:

Well, we use pk_group_enum_to_text to get the gettext localization. The
frontend gets a list of groups from the GetGroups() method call - which
means we don't show the groups where we have no packages.

> > > > > It would be nice to have a supported and third party filter in
> > > > > PackageKit. But this could also be decided in the frontend.
> > > > 
> > > > Can you define supported and third-party for a general case? Then we can
> > > > work on how these filters could map to others like yum (where livna is
> > > > unsupported) in a more general sense.
> > > > 
> > > > But overwise, adding more filters is a good thing to do.
> > > 
> > > This issue affects mainly company driven distributions that don't make a
> > > difference between a professional and community edition, e.g.
> > > Canonical/Ubuntu.
> > 
> > Sure. supported and ~supported seems a sane thing to add. Better names
> > welcome.
> 
> They seem to be ok.

Cool, I've added supported and ~supported.

> > > In Ubuntu we mark applications that are not officially part of Ubuntu as
> > > third party applications. This helps to promote software from the
> > > partner repository and also allows user to easily identify alien
> > > software that could also be a source of problems.
> > 
> > So we only need one filter? i.e. distro certified and non-supported?
> 
> Actually two. There is also software that comes from third party
> repositories and are not supported, e.g. medibuntu (multimedia addons,
> could be compared to livna).

So if supported is "If the package is supported or is a third party
addon." what would the other filter be called? Feel free to change the
description of supported if required.

Richard.