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
(A.7.) could be a first shot on this problem.
Could branches for your cron job's autodock checkout differ? The page was
this morning but yet not references. Or is there a second directory
the source package name is "autodocksuite" (because of the joint autogrid
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
* information in d/u/metadata associated with a particular set of
binaries with the same or different names shall be listed in a "binary:
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?