[packagekit] PackageKitExtra - package abstraction
glatzor at ubuntu.com
Tue Feb 19 08:10:12 PST 2008
Am Dienstag, den 19.02.2008, 10:37 +0100 schrieb Patryk Zawadzki:
> On Feb 18, 2008 6:59 PM, Richard Hughes <hughsient at gmail.com> wrote:
> > On Mon, 2008-02-18 at 12:09 +0100, Sebastian Heinlein wrote:
> > > To achive this all .desktop files are extracted from the archive and
> > > stored in a cache with some extra information. Currently all desktop
> > > files are shiped in the app-install-data package so that the cache can
> > > be rebuild afterwards again.
> That's a horrible horrible hack and would be a huge pain to maintain
> in a consistent and up-to-date way for any distro with daily updates
> (think "* unstable" or always-in-development distros).
It was written for a distribution with stable releases. The desktop
extraction is more or less automated using scripts. Futhermore this is a
description of the current state and not a promotion for a general
> > > Here is the list of extra attributes that we use:
> > >
> > > * X-AppInstall-Package
> > > Name of the corresonding package
> > Sure.
> This belongs to "xdg online desktop" (currently mugshot).
Sorry, but I am not familiar with mugshot. So could you please say some
words about your idea.
> > > * X-AppInstall-Architectures
> > > The architectures which are supported by the package
> > Is this important?
> Same question here, if the architecture is not supported, user should
> not even see the package. It's not like you're gonna buy a new PC to
> install a package.
Since app-install allows to enable repositories you have to find a way
to determine if a package is not available since the repository is
disabled or it is not availabe for the architecture.
Furthermore lots of users are not aware that you cannot install every
application on every architecture: flash is a good example.
From an usability point of view it makes sense to show a result if the
users searches for flash and to add an information that it is not
> > > * X-AppInstall-Supported
> > > Is it supported by Canonical?
> What if it's supported by a third party? Like nero for linux (which is
> crappy software but supported by ahead).
Support refers only to supported by the distributor, which in this case
> > > * X-AppInstall-Channel
> > > Label of a third party repository that contains the package of the
> > > application and needs to be enabled before.
> > You mean installing an application install can enable and then disable a
> > repository? Isn't this a security risk?
> Agreed, if packages can add/remove/enable/disable repos at will, the
> whole distro repo concept is crippled.
The repositories stay enabled after installation. Some time ago the
universe section of Ubuntu was not enabled by default. So we translated
the "enable universe section" action to a human readable dialog: Do you
want to install software that is maintained by the Ubuntu community?
> > On top of this it is trivial to build an executable like
> > pk-command-not-found which does the prompting for installation (rather
> > than telling the user what to do) as we can now install as non-root.
> Ugh. That would mean I can type stuff like sperl to install a suid
> binary (security problem). I don't think the whole feature would be
> all that useful. Your casual Jane User is very unlikely to launch a
> terminal and type stuff like "firefox" while an admin would certainly
> just install apache instead of typing "apachectl" and waiting for the
> shell to install random pieces of software.
There are also power users and not only Jane and admin ones. Take a look
at all the howtos and wikis that are available today and which include
There is no automatic installation. So I don't see your security
concern. If it is a security sensitive environment a novice user should
not have the permission to install software at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
More information about the PackageKit