[packagekit] PackageKitExtra - package abstraction

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

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

> > * X-AppInstall-Popcon
> > Integer that gives an idea how popular an application is. Calculated
> > from user statistics.
> From where? I figured we could use the mugshot stats for this.

Same as above.

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

> > * X-AppInstall-Proprietary
> > Does it contain non-free code?
> Surely a licence would be a better field? Then the daemon can decide
> what is free and what isn't.

Looks like this is just a local interpretation of license.

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

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

> > * X-AppInstall-Codecs
> > List of codes that are supported by the application. There are some
> > manual created applications for codec packages.
> A list of mime/types?

This belongs in the package headers/repo indices. Think rpm's
Provides: mime(foo/bar) or deb's counterpart. Should be handled by
backends.

> > * X-AppInstall-PatentBadness
> > Possibly problematic code inside.
> Surely Proprietary == PatentBadness from a user's point of view?

Not really. Nero for Linux is proprietary but not patent crippled,
ffmpeg is opensource but considered prone to patent wars.

> > If you type in a not installed command into your terminal, Ubuntu
> > currently looks in to a command cache and presents packages that provide
> > this command:
> >
> > renate at laptop:~$ ncftp ftp.ubuntu.com
> > The program 'ncftp' can be found in the following packages:
> >  * ncftp
> >  * ncftp2
> > Try: sudo apt-get install <selected package>
> > bash: ncftp: command not found
> This is very cool for new users and something that I've sorely wanted in
> Fedora for new users. How do you generate the binary->package table and
> keep it updated?

Just ask repo indices for a package that contains a particular binary?
Looks like backend's job.

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

-- 
Patryk Zawadzki
PLD Linux Distribution