Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Support for RPM spec files #847

Open
tpgxyz opened this issue Dec 14, 2018 · 5 comments
Open

Support for RPM spec files #847

tpgxyz opened this issue Dec 14, 2018 · 5 comments
Labels
T: feature-request Requests for new features T: new-ecosystem Requests for new ecosystems/languages

Comments

@tpgxyz
Copy link

tpgxyz commented Dec 14, 2018

Hi,

i think it will be a great feature if dependabot could support RPM's spec file.
There are a lot of projects and organizations that keep RPM sources on github, and they can easily benefit from dependabot
Parsing spec file's entries
Name:
'Version:'
'Patch*:'
'BuildRequires:'

for name's version, patches (official CVE), versioned buildrequires.

@greysteil
Copy link
Contributor

Totally up for this! Can you add some links to docs and example files, so this is easier to pick up whenever I can prioritise it? 🙂

@tpgxyz
Copy link
Author

tpgxyz commented Dec 14, 2018

@greysteil Here you go:
http://rpm.org/documentation.html
https://rpm-guide.readthedocs.io/en/latest/rpm-guide.html#what-is-a-spec-file

What is most important here is to parse spec file. Based on "main" Name: in spec file you can get the name of the software, and then you can solve either there are some CVEs or any specific versioned dependencies.

Here how typical RPM source looks like before it will be compiled to its binary form:
https://github.com/OpenMandrivaAssociation/libtiff/

@waghanza
Copy link

@greysteil Parsing rpm is very hard (at least because of rpm exists per distribution, I mean that a rpm spec for fedora COULD NOT be parsed the same way as a rpm spec for centos)

A great parser supporting a reasonable amount of rpm spec version could be found here => https://github.com/bkircher/python-rpm-spec

@stale stale bot added the wontfix label Oct 23, 2019
@feelepxyz feelepxyz added T: feature-request Requests for new features and removed wontfix labels Oct 23, 2019
@jeffwidman jeffwidman added the T: new-ecosystem Requests for new ecosystems/languages label Aug 23, 2022
@dependabot dependabot deleted a comment from stale bot Aug 23, 2022
@bish0polis
Copy link

bish0polis commented May 10, 2023

Based on "main" Name: in spec file you can get the name of the software

Nah. Grab the /^source[0-9]*:/i lines . This tells you the upstream source project, and usually its version.

Also, build-donkey hosts with the RPM toolset installed - so, every RPM-based host out there - can perform a quick spectool to grab the current source/patch list (and we maybe don't care about the latter) from a given spec file.

spectool is a python tool at pagure.io/spectool . I'm thinking it's got parsing magic that can be ported in if shelling out is too dumb too often.

TL;DR - sources we'd care about are plainly available in the spec-file to any buildbox/ci-donkey with basic tools installed, so dependabot checking upstream versions - by version - is completely possible.

Don't discount this task -- it's not gonna be easy, but it's not as hard as we fear it's going to be.

@tpgxyz
Copy link
Author

tpgxyz commented May 24, 2023

The idea is not to parse src.rpm files, but to parse .spec files that are available as plain text in github repo.

Take into account this https://github.com/OpenMandrivaAssociation/libtiff/
So dependabot should open the https://github.com/OpenMandrivaAssociation/libtiff/blob/master/libtiff.spec file and look for a Version: and parse its value i.e Version: 4.5.0 Then compare 4.5.0 with already existing libtiff version in dependabot db as latest released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: feature-request Requests for new features T: new-ecosystem Requests for new ecosystems/languages
Projects
None yet
Development

No branches or pull requests

6 participants