[packagekit] Properties and Supported

[Sebastian Heinlein]

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.

> > , licence
> 
> GetDescription()


> > 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.

> > section
> 
> Like group?

I would like to make further use of the sections in the update tool. I
want to add an additional view that abstracts the long list of packages
to applications and where no corresponding application can be found to
sections.

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.

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

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.

- seahorse        =>  Passwords and Encryption

- abiword         \
- abiword-plugins | => abiword source package => Abiword Text Editor
- abiword-gtk     /

- libx           \
- libxrandr      |
- libx           | => x11 section => Graphical User Interface
- xserver-xorg   /  

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

> > , 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.

We already have got a solution for this in Ubuntu but I think it would
be nice to have this in GNOME.

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.

> > 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.

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

gettext.dgettext("packagekit", "Audio")

> > > > 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.

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

Cheers,

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20080215/94eff8f7/attachment-0004.pgp>