[packagekit] Properties and Supported

[Sebastian Heinlein]

Am Sonntag, den 17.02.2008, 19:09 +0000 schrieb 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?

I would like to have a fixed reference point. 

Right, the label is enough. Nevertheless not all repository admins add a
label, but in these cases the backend should create a meaningfull name
from the URL.

What about the third party attribute? Should we handle this in the
backend or the frontend? So only providing the origin of a package and
let the frontend decide if it is part of the distro?

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

I am afraid that the GetDescription string gets quite long.

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

Right, I was just explaining how the new update-manager view would work.

But what I have forgotten is the source package attribute. It is
fundamental for the new update-manager view.

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

I will take a look at the Debian sections. Perhaps we can map them all
to PackageKit groups or extend them by need.

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

Right, perhaps they should only be used in the SearchDetail backend
method.

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

Not really. One filter is "Package is support by the distributor". The
second one could be called "Package is provided by an ISV" (independent
software vendor) or "Third party software". In the case of Ubuntu e.g.
opera would appear in both groups: It is part of the Canonical partner
repository, so not part of Ubuntu, but supported by Canonical.
-------------- 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/20080218/a2d98d72/attachment-0004.pgp>