Re: d/u/metadata for binary or source tree Re: RRID update on salsa on packages starting with A+B
On Wed, Apr 04, 2018 at 01:56:42PM +0200, Steffen Möller wrote:
>
> > 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
I have no idea what you might consider *Blend* *specific* in using
Salsa. Everything worked before Salsa and the fact that Git
repositories now can be changed via web form has nothing to do with
Blends. Am I missing something?
> and the screenshots and translations is missing.
That's perfectly generic Debian stuff. Well, I admit I wrote the
UDD importers for screenshots and translations because I intended
to use it on the tasks pages. But it is used in very different
places for all Debian packages. So what exactly do you want to be
documented here? (Patches welcome)
> > 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.
Can you please re-read
https://lists.debian.org/debian-med/2018/03/msg00119.html
Seek for "For citations we are using the field Debian-package"
> 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
That's the case.
> * d/u/metadata also refers to the binary with the same name as the source
> tree.
That's also the case (more or less unintended but it is working like
this).
> * 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
See my posting.
> 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.
Hmmm, I do not understand what you mean. Fixing the massxpert package
is only one commit away:
https://salsa.debian.org/blends-team/med/commit/6451da2d816f762cf391f048676c79eee1c25431
Please, if anybody notices this, just fix the according task instead of
assuming intentional displaying cruft. Its not *that* hard to do to
replace an outdated package name by a correct one.
> 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.
I guess you want to invent some extra layer of complexity for d/control
which will never be accepted to solve a problem for Registry entries
which was just solved for citations. We just need a *decision* I was
asking for in the end of the mail I was linking to above.
> 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.
Having data relevant for *binary* packages in a dir named *upstream*
does not sound very logical for me.
> For d/u/edam we had the concept of a summary representing the packages as a
> whole and then subsections for every binary.
I admit I do not fully understand the edam data. I guess the only
reason that we are not facing issues with these data is that they are
just stored in UDD and the only (non-)use case is some query that
exports the data again. I doubt that anybody has done some QA on the
output.
> 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?
Again: I think that what we implemented for citations (Debian-Package
field) which is documented in Wiki[1] is absolutely sufficient to solve
the problem we have. I see no reason to invent something else. The
only thing that we should think about is the data storage model: Do we
use another column as in the bibref table or should the importer
translate the data right to binary packages according to the algorithm
above:
If source package = binary package if nothing else is specified.
Use Debian-Package as binary package name otherwise.
It depends a bit from the applications that will consume that data. For
the moment it is only the Blends web sentinel which is rather binary
package centric. The bibref table layout is rather a hack I created
afterwards after we were running in the perfectly same problem as we
have now with references. May be a binary package based table layout
is more sensible.
> I cannot judge how much of a hassle it is to fiddle anything like that into
> the UDD. What do you think?
I keep on thinking that the established method is not much of a hassle
and repeat my question whether you might imagine other use case
applications for that data which might rather be source package centric.
The only "drawback" is that this use case has an additional JOIN in the
SQL query.
Kind regards
Andreas.
[1] [1] https://wiki.debian.org/UpstreamMetadata#Fields
--
http://fam-tille.de
Reply to: