[packagekit] Properties and Supported
Robin Norwood
rnorwood at redhat.com
Fri Feb 15 09:31:49 PST 2008
On Fri, 15 Feb 2008 12:26:08 -0500
Robin Norwood <rnorwood at redhat.com> wrote:
> On Fri, 15 Feb 2008 18:07:25 +0100
> Sebastian Heinlein <glatzor at ubuntu.com> 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, licence, support, section, tags,
> > supported mime-types and codecs.
> >
> > Why did you decide to hardcode the list of groups? Should the
> > frontends not be able to deal with flexible groups/sections?
> >
> > > > 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.
> >
> > Canonical only provides support for a 'small' number of packages
> > that are located in the main component and the software from the
> > partner repository. Furthermore desktop packages are only supported
> > for 3 years and server packages for 5 years in a Long Term Release.
> > Hardy 8.04 will be such a LTS release. The software in universe is
> > basically maintained by the community and so not officially
> > supported by Canonical.
> >
> > 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.
>
> How is that implemented, out of curiosity? In Fedora/rpm terms, we
> have a 'Packager' string and a 'Vendor' string, but so far as I'm
> aware, none of our tools use them, and they are both set to
> 'Fedora Project' by our build system. I don't think they're currently
> used by much, or enforced at all, but one or both of these sound
> equivalent to the concept you're describing in Ubuntu. A quick glance
> at the livna-release rpm (livna is sort of like ubuntu's universe, but
> not officially pointed to by Fedora because they provide some 'not
> free/possibly illegal for Fedora to distribute' software) shows:
>
> Packager : rpm.livna.org <http://bugzilla.livna.org>
> Vendor: rpm.livna.org
>
> So at first glance it looks like that data might be useful for PK to
> show in Fedora as well.
I forgot to mention the GPG signing aspect! All official Fedora rpms
are signed with our key, of course. Non-official rpms are either
signed with another key, or not signed at all.
I talked with Seth Vidal on IRC, and he sees no use at all in the
Packager/Vendor strings, since of course they can be set to whatever
the rpm builder wants. There might still be some value, I think, but
of course nothing you'd want to trust. Since they aren't really used
by our existing tools, we might not want to show these tools for the
yum/fedora packagekit, which should be fine.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit
mailing list