Dear all,

In the Debian Med and Science teams, we are looking for efficient ways to
document slow-changing metadata relevant to our packages, in particular:

 - Bibliographic information: which article to cite when a software is used
   in a published scientific work. This can be summarised by a digtal object
   identifier, like http://dx.doi.org/10.1016/S0168-9525(00)02024-2, or
   without the reslover part (http://dx.doi.org/). 

 - Registration information: where is the registration page that the users
   would have had to go through if they had not used our packages.

These two pieces of information are crucial to researchers who periodically
need to justify the spending of public money in maintaining academic software.
Usefullness is often measured by counting citations or registered users, and
the Debian popcon scores are not a good replacement since they are either
skewed (install) or under-estimations (votes), and that anyway they only count
the Debian contribution. 

One possibility to guide our users to the upstream registration page is to use
Debconf. I think that I do not need to explain on this list why it is not
satisfactory.

Alternatives will be much easier to build if we manage to centralise the
information in a common place. This could be in the source packages themselves,
either in a dedicated file or in debian/control (but not necessarly ending in
the Packages and Sources files), or in the file we use to create our
metapackages. Ultimately we would like to be able to have this information flow
in places like the Ultimate Debian Database and the web pages proposing the
packages for download.

If the concept is popular, it could be expanded, in particular to the software
that allow the users to contribute some money (the now famous “Paypal
buttons“).

The two possibilities that do not require much new development, storing the
meta-data in the source packages or in metapackages, have some opposite
features. In particular, if the meta-data is in the source packages, but not in
the Packages and Source files in the mirrors, then it becomes difficult to
access it when the source package is not stored in a VCS.  Conversly, if we
store the meta-data in our metapackages, the data is easy to access to us and
the users of the Debian Blends, but not to those who use the packages directly,
unless we commit ourselves to feed central information places like the Ultimate
Debian Database and to keep the information up-to-date, which will be at best
limited to the packages relevant to our projects.

I am therefore seeking comments and insights to better manage our packages
metadata.

Have a nice Sunday,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to