[packagekit] Managing applications with app-install

[Duncan Mac-Vicar P.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Hughes wrote:
> It would be interesting to see how many other distros can adopt this
> metadata format. We would be willing to make changes and add
> functionality if this is a blocker to acceptance.

Hi guys, I think this is a great step to have all this around PackageKit.

I think this goes a bit against the design of PackageKit and exposes to
much implementation details, especially using SQL commands as the data
transport. We already have our efficient string storage cache, I don't
see much reason to go for sqlite as the main format, because you are
assuming much about the distribution, and that is what PackageKit was
supposed to "fix".

Why not shipping the data in the data package with the same desktop file
format? With lzma it should compress well.

On our full unpacked distribution, taking all /usr/share/applications
plus kde3 desktop files ends with 1077 applications,, if you concat them
all together is just 1015k, 215k compressed with lzma.

Adding the extra keys (package, etc) and remove non-needed one, the size
won't change much (well + translations and icons, but that is there with
 any format).

I think we can parse that very fast and keep it in a solv file.

I don't feel confortable with one package per repo either. Who makes
sure this package is installed? Fedora and Debian have a couple of main
repositories, but openSUSE has the build service where there are a lot
of repositories which are small projects... therefore the amount of
"data" packages would explode. I think it is a "way" to do it, but
should not be "the way".

The script could be fully standard across distros, by just concat all
desktop files together and apply some transformations, so:

[Desktop Entry]
X-SuSE-translate=true
Categories=TextEditor;
Encoding=UTF-8
Name=Emacs
GenericName=Text Editor
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Exec=emacs %f
Icon=emacs
Path=
Type=Application
Terminal=false
X-KDE-StartupNotify=false

Would become something like:

[emacs]
Categories=TextEditor;
Name=Emacs
GenericName=Text Editor
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Icon=emacs
X-PackageKit-Package=emacs-core
X-PackageKit-...=...
...

The fact that this data could be available in some standard location,
like /usr/share/appdata or whatever, doesn't mean we need to force how
the data comes there. Installing one rpm per repo may be a solution, but
I would like PK to not assume how that happens.

Then, once the data is there, each PK backend should cache in its own
way. We really would like to use solv files because they are fast, and
we already moved away from sqlite. If Fedora wants to ship a cached
sqlite db so yum can access it easily is fine, but for us does not help.

What may be can help is to make PK provide default implementations.
Something similar as I mentioned to the history feature. If our ZYpp
backend implementes the applications api (listing, etc) via the backend,
we can scan the desktop files in libzypp and create the solv files from
the desktop files. If the backend does not implement it, you could
assume the desktop files need to be inserted in the sqlite db (or
converted to sql if the cache is not there). For the transaction history
we would like to have something similar, so we can plug our history
model in the PK API, but PK providing default "implementations" makes
features to be consistent across the desktop.

Duncan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkm3k8kACgkQzR62qWZ+QtFLHQCgg7OAbeW6It6m7QH06sj6HZ7V
sUQAn2dPBGRLOq/qeKE8mQi79xUSLRoi
=Mq8J
-----END PGP SIGNATURE-----