Moving information from tasks files into Vcs
- To: NeuroDebian Team <email@example.com>, Debian Pure Blends List <firstname.lastname@example.org>, Debian Med Project List <email@example.com>, Debian Science List <firstname.lastname@example.org>, DebiChem Project <email@example.com>
- Cc: Debian Edu Project List <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Debian GIS Project <email@example.com>, "Debian Jr. Project List" <firstname.lastname@example.org>, Debian Lex List <email@example.com>, Debian Multimedia <firstname.lastname@example.org>
- Subject: Moving information from tasks files into Vcs
- From: Andreas Tille <email@example.com>
- Date: Thu, 7 Jun 2012 14:27:24 +0200
- Message-id: <[🔎] 20120607122724.GA20372@an3as.eu>
- Reply-to: Debian Pure Blends List <firstname.lastname@example.org>
[For the not so scientific Blends teams: the intend to work on
scientific publication data has lead to other improvements also for your
maintenence of tasks files ... even if I'm afraid that some teams do not
really maintain their tasks files and possibly do not even know that
I intend to get rid of all Publication-* fields in the Blends tasks
files which had some other interesting side effects. While publication
data can very easily be moved to debian/upstream files for just
uploaded packages sligthly more work is needed for not yet packaged
software. To solve this problem I wrote a gatherer for machine-readable
files in Vcs and an UDD table is feeded with this information. This
has two consequences I'm personally consider quite handy:
1. You can remove all additional information from prospective
packages if it is just in Vcs. In case you might have watched
the changes in med-bio task you mighht have noticed my step
by step removals of additional information after checking SVN
2. If a package is not even in Vcs you can actively move the
information from tasks files to Vcs. This minor effort has the
advantage that a part of the actual packaging work is done (well,
if you do not intend to package this software it could simply be
removed from the tasks file - we are not just another list of
software.) The result is that you have a better structured way
to keep the information.
The good thing in this approach is that the duplication of data between
Vcs and tasks files could be stopped which simplifies the maintenance.
Moreover the gatherer for machine-readable files is doing some checks
for mistakes (I was able to fix some broken Vcs URLs for instance).
If you wonder what machine readable files are parsed you could use
the template files in
The following information is parsed:
- source name
- WNPP bug number (if it is closed in the *latest* changelog entry)
- Vcs-Browser (which is verified against the location were the
packaging stuff was really found in the Vcs tree)
- Short name of license which belongs to the section "Files: *"
- citation information (if exists)
This is basically the information in a complete entry for a prospective
package. The code for the Vcs parser is available at
It is a pure sh script and parses the following Vcs URLs:
These are dirs on alioth and the script is running on Alioth once per day.
If you know other Vcs locations which might be relevant for your Blend
just tell me (if it is some non-SVN / non-Git repository I might need
some technical help how to extract the relevant files).
1. Maintain your tasks files
2. Add your packages (binary package names!) in Vcs and
the appropriate sections will automagically show up in
the prospective packages section (so the Blends doc
needs some update about the now depreciated Vcs fields)
3. Clean up your task file from now useless stuff if the
packaging is in Vcs.
4. Turn information from tasks files into packaging code
in Vcs if not yet there
5. Move Publication-* fields from tasks files to Vcs
I hope you like these modifications that are intended to simplify
PS: Reply-To set to debian-blends list.