On 4/3/18 5:09 PM, Andreas Tille wrote:
One half done. The invitation to contribute to salsa and the screenshots and translations is missing.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.
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