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


(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
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
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?



Reply via email to