On 4/3/18 5:09 PM, Andreas Tille wrote:
On Tue, Apr 03, 2018 at 12:27:08PM +0200, Steffen Möller wrote:
There is a daily cron job parsing Salsa directories.
Fine. Somewhere there is (or should be :o) ) a documentation how this page
is crafted. On our Wiki? Let us then have a link to that page.
May be this
https://blends.debian.org/blends/apa.html#datagathering
(A.7.) could be a first shot on this problem.
One half done. The invitation to contribute to salsa and the screenshots
and translations is missing.
Could branches for your cron job's autodock checkout differ? The page was
updated
this morning but yet not references. Or is there a second directory
"autodock" when
the source package name is "autodocksuite" (because of the joint autogrid
tool)?
That's not about branches. As previously said: Registry data are per
source package currently. There is no means in the registry data table
to map an entry to a binary package. Thus autodock *and* autogrid are
missing registry data both.
There was one d/u/metadata file that assigned different references IIRC
to different binaries of that source package by inventing a
sub-hierarchy. This seems to indicate that this is not only an issue for
the registry entries. How about the following:
* d/u/metadata always refers to the source tree as a whole
* d/u/metadata also refers to the binary with the same name as the
source tree.
* information in d/u/metadata associated with a particular set of
binaries with the same or different names shall be listed in a "binary:
" attribute
Admittedly, I see some issues with that. The notion of a reference
binary for a package with many binaries would be helpful for Debian in
general. This would prevent something like the Massxpert entry on our
task list that describes itself as a transition package. But this also
means that such notion about, say, "end-user relevant" packages vs
technical helper packages because of arch-independency or libraries etc,
should be declared in d/control.
Another concern of mine is that we typically do not tag any data for
being specific for something. We put it in different files. As such, we
would need d/u/<binary>.metadata.
For d/u/edam we had the concept of a summary representing the packages
as a whole and then subsections for every binary. I kind of liked it the
way it is, but maybe separating that out to different files would also
be appropriate. Could there be an option to do it either way?
I cannot judge how much of a hassle it is to fiddle anything like that
into the UDD. What do you think?
Best,
Steffen