| Re: [sw360-dev] Oldie but goldie: Component Identification |
On Fr, 11. Jan 11:12, Kristan Johannes (INST-CSS/BSV-OS1) wrote: > We just define another external id "purl" which stores the purl. Is the purl unique? Or is it like a classic URL and there are multiple representations of the same resource. Especially for docker, where the non-deterministic build yields different hashes. Or also the case where the same artifact is distributed over different tools (e.g. the zoo of tools for JS). I think a release should at least have a list purls, and two releases are equal if at least one of them matches. This also means that non-matching purls do not imply that the artifacts are not equal. In my opinion, if one knows coordinates and file-hashes of some artifact, one can generate a list of identifying features. And some of these features could be encoded as a purl. Best regards Maximilian On Fr, 11. Jan 11:12, Kristan Johannes (INST-CSS/BSV-OS1) wrote: > Hi, > > I am not one hundred percent sure what the actual proposal is. However, I > think it is generally a good idea to store the purl for a component. Shouldn't > this already work with our external id concept. We just define another > external id "purl" which stores the purl. > > In antenna we had similar discussions about coordinates and introduced a > hierarchy of possible namings for components, from very generic ones, eg just > the filename, to specific ones like maven coordinates. This allows to cover > all types of identified components and you don't need to miss any. > > Kind regards, > Johannes > > Mit freundlichen Grüßen / Best regards > > Johannes Kristan > INST-CSS/BSV-OS > > Tel. +49 30 726112-432 > > > -----Ursprüngliche Nachricht----- > Von: sw360-dev-bounces@xxxxxxxxxxx <sw360-dev-bounces@xxxxxxxxxxx> Im Auftrag von Michael C. Jaeger > Gesendet: Freitag, 11. Januar 2019 11:54 > An: sw360 developer discussions <sw360-dev@xxxxxxxxxxx> > Betreff: [sw360-dev] Oldie but goldie: Component Identification > > Hi, > > I am sitting here with Alex from Codescoop and we are discussing how to match component entries between two systems. eventually we do not see another approach than > > * use the artefact management domain as part of the identification for a component > * allow for some low percentage missing mappings to get it actually working > * because any own ids are not suitable > > The next thing is how to actually apply a common naming for things like maven, nuget, pypi, composer, deb etc etc. because also you could have a decision on "mvn" or "maven", or composer vs cmp, and more discussions alike and how to have a compiled list on the first hand. > > Of course we remember the purl proposal by Philippe and we are very much fond of taking the purl proposal for a definitive list of "artefact management domain" names which referred there as type: > > https://github.com/package-url/purl-spec > > -> see "Known purl types" > -> see "Other candidate types to define" > > Any other thoughts on this? > > in SW360 on component level we would need to add the field "type" and rename the existing field "category" (where we put value like "lib", "tool", "application", "database", etc.) to be consistent, but I think it is worth it, because the potential for solving a mapping problem and enabling a lot of use cases is huge. > > Kind regards, Michael > _______________________________________________ > sw360-dev mailing list > sw360-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sw360-dev > _______________________________________________ > sw360-dev mailing list > sw360-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sw360-dev -- Maximilian Huber * maximilian.huber@xxxxxxxxxxx * +49-174-3410223 TNG Technology Consulting GmbH, Beta-Str. 13a, 85774 Unterföhring Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Müller Sitz: Unterföhring * Amtsgericht München * HRB 135082
Attachment:
signature.asc
Description: PGP signature