Hello!
With more and more non-technical users using Linux and Debian, the
package database became much more application-centric instead of
package-centric, as it was before. This resulted e.g. in the Ubuntu
Software Center and GNOME-AppInstall as simple ways for endusers to
install software.
In order to provide these "Software-centers", additional metadata was
required, which is currently stored in the package "app-install-data",
which is a very inflexible way of storing this data. The data also has
to be rebuild for every distribution release, which is a problem e.g.
for the unstable or testing "release" of Debian, which is used by many
people.
In January, people from many distributions met in the "AppStream
Meeting"[1] to define how an application-centric Software Center
should look like and how distributions could collaborate and share
technology in this area. Sharing stuff would reduce work on all sides
and have some nice side-effects, e.g. better collaboration on patches.
It also improves upstream relations. For more information on
AppStream, you can check the wiki page at fd.o. ([1])
Also, Debian lacks some package-neutral metadata other applications
could use to request a specific "extension" to be installed. E.g. the
Anjuta IDE uses this metadata available on Fedora to install some
plugins. With additional metadata in the Debian archive, applications
using the distribution-neutral PackageKit API could e.g. request a
specific firmware, mimetype, USB-Device handler etc. to be installed.
To solve this issues and to provide a complete and smooth experience
for non-technical users, we created DEP-11, which describes how the
Debian archive could be extended to support these additional features.
Please do always keep in mind that this data will be optional and will
be downloaded on demand, so it will be present on desktop machines,
but not on servers, where it doesn't make much sense.
AppStream features XML to store metadata. Because we don't use XML
somewhere in Debian, DEP-11 features a well-known RFC822-style format.
The metadata to provide "applicataion-data", which is information
about which package contains which application and "component-data",
which is information about which component (shlib, python-module,
firmware, mimetype, driver, ...) a package provides can be created
automatically in one pass. It also covers the same use-case, therefore
it makes sense to store it in one file.
Implementing this should be trivial. Some people are already working
on Python scripts to extract the required data very, very fast and
Michael would implement some additional methods into apt to support
the new files. It is also possible that package-maintainers could
define custom "Component-Provides" for their packages - this would
make sense in some cases, if the provides entry is the same on all
distributions.
Tools like Apper for KDE already support installing Plasma-Dataengines
from the archive, if metadata is present.
So, there are many people who would like this feature, also many
upstream developers. (I talked to them at Desktop-Summit this year)
Implementing and using this new feature is not a problem :)
So, do you have any comments/complains/improvements for DEP-11? Would
you generally agree that adding this data is useful?
You can find the full text of DEP-11 at [2].
I CCed debian-devel, so more people can comment on this.
Thanks for the attention!
Kind regards
Matthias Klumpp
-------
[1]: http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011
[2]: http://wiki.debian.org/AppStreamDebianProposal
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKNHny_biK3h72yC9D0=3qtuzv1ywxfrsv+a7yulbge_d4h...@mail.gmail.com
