Purl Generation Alpine

[ThiefaineM]

Describe the bug
The generated purl for alpine composants does not match the one use in OSSINDEX.

To Reproduce
Steps to reproduce the behavior:
1- Create a Docker with an alpine image such as postgres:12.0-alpine
2- Use Tern to generate a BOM in cycloneDx json format
3- Look at the purl generate: for example the one for libxml2

Expected behavior
It seems that for alpine the purl looks like "pkg:alpine/libxml2@2.9.9-r2" instead of "pkg:apk/alpine/libxml2@2.9.9-r2". Here the two result depending on the purl :
https://ossindex.sonatype.org/component/pkg:alpine/libxml2
https://ossindex.sonatype.org/component/pkg:apk/alpine/libxml2
It looks like that for alpine the package type should not be written

[ivanayov]

Can I work on this?

[rnjudge]

@ivanayov I think @ThiefaineM already opened a PR with a fix for this.

[rnjudge]

@ThiefaineM Mentioned this in my PR, but it does not look like apk/alpine packages are actually defined in the purl spec so curious why ossindex has a preference, do you know?

[ThiefaineM]

I do not have an idea on why they did it like this sorry.
Nevertheless by looking at the spec, I saw that Python packages (with others) should have their name is lowercase. But it is not the case as generated purl for Django is : "pkg:pip/Django@3.2.3"
Should I create an other issue specific to it ?

[rnjudge]

I do not have an idea on why they did it like this sorry. Nevertheless by looking at the spec, I saw that Python packages (with others) should have their name is lowercase. But it is not the case as generated purl for Django is : "pkg:pip/Django@3.2.3" Should I create an other issue specific to it ?

Yes, please. By the way, I opened an issue in the purl repository asking about the alpine/apk purl type entry. It would make me feel better to have a specified Alpine type in the purl spec before merging your PR but I'll see what they respond with. I'm not opposed to merging your PR if the purl maintainers seem agreeable with the current ossindex expectation.