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