Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

distro is passed as None for RPM packages #3443

Open
TG1999 opened this issue Jun 30, 2023 · 8 comments · May be fixed by #3770
Open

distro is passed as None for RPM packages #3443

TG1999 opened this issue Jun 30, 2023 · 8 comments · May be fixed by #3770

Comments

@TG1999
Copy link
Contributor

TG1999 commented Jun 30, 2023

Description

For debian based packages we pass namespace=distro here https://github.com/nexB/scancode-toolkit/blob/8ed266372416a4e55cf739dadafa175214dca980/src/packagedcode/debian.py#L634 but never passes distro apart from the case where it's distroless.

How To Reproduce

Look at the issue details

@TG1999 TG1999 added the bug label Jun 30, 2023
@ai-naymul
Copy link

Hey @TG1999 , did you mean handle "None" value for 'distro' or set a default value to distro?

@johnmhoran
Copy link
Member

See also Input PURL does not match output PURL #1274, just added a few minutes ago.

xonx4l added a commit to xonx4l/scancode-toolkit that referenced this issue Aug 30, 2023
@xonx4l
Copy link

xonx4l commented Aug 30, 2023

A rough idea from my side . what you think @TG1999 .

@pombredanne
Copy link
Member

Some hints for solving this:

  1. the distro needs to be found first. There may be several ways to do this either based on data available inside a package (a .deb), in its version or name (where there may be a hint that it's from Ubuntu), or in the rootfs for installed packages where we can collect a distro in https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/distro.py

  2. once found, use this as the namespace

  3. if not found, should we have a default? I am not sure, yet using debian may make sense?

@mjherzog
Copy link
Member

mjherzog commented Sep 1, 2023

Don't we have the same/similar problem for redhat, fedora or centos for type=rpm? We need some well-documented default in all cases

@pombredanne
Copy link
Member

Don't we have the same/similar problem for redhat, fedora or centos for type=rpm? We need some well-documented default in all cases

Yes! The issue exists with RPMs too

@pombredanne pombredanne changed the title distro is passed as None for debian based packages distro is passed as None for debian and RPM packages Sep 1, 2023
xonx4l added a commit to xonx4l/scancode-toolkit that referenced this issue Sep 2, 2023
@AyanSinhaMahapatra
Copy link
Member

This is fixed for debian by the following PRs:

We need to do something similar for RPM.

@AyanSinhaMahapatra AyanSinhaMahapatra changed the title distro is passed as None for debian and RPM packages distro is passed as None for RPM packages Apr 4, 2024
@pombredanne
Copy link
Member

For RPMs, the same thing to do is IMHO to use the /etc/os-release "identifier" field ( as in identifier: rhel) for the distro. And use this as a namespace for the RPM PURL.

AyanSinhaMahapatra added a commit that referenced this issue May 8, 2024
Update debian, rpm and alpine package assembly to get
distro identifier and then set this properly to
created package, dependency and package_uid instances.

Reference: #3443
Signed-off-by: Ayan Sinha Mahapatra <ayansmahapatra@gmail.com>
@AyanSinhaMahapatra AyanSinhaMahapatra linked a pull request May 8, 2024 that will close this issue
6 tasks
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants