Description of problem: rdopkg uses Yum's rpmUtils.miscutils.splitFilename() method, like so: def nvr2version(nvr): _, v, _, _, _ = rpmUtils.miscutils.splitFilename(nvr) return v DNF does not provide the splitFilename() method (it was dropped in https://github.com/rpm-software-management/dnf/commit/648c961ce145ede20c482ccd5d948cc665a340c1) This hinders porting from Python 2 with Yum to Python 3 with DNF. Version-Release number of selected component (if applicable): dnf-2.4.1-1-12-g54b800a Additional info: The Copr project has already hit this pain point as well. Initially they switched from Yum to DNF's implementation: https://pagure.io/copr/copr/c/6ab5306fe948a6e42ed8ce39d0f622473606040c Now they've copy-pasted the method definition in their own code: https://pagure.io/copr/copr/c/1d49db6ac4be993ce7c0e6621758b313b8026ec8 Would you please restore this method in DNF, or point us at a suitable replacement?
I created a pull request that partially should help (https://github.com/rpm-software-management/dnf/pull/828). First of all you have to split dir path and file name, then remove .rpm or srpm surfix from file name, and remains should be parsed by new method like ``` subject = dnf.subjet.Subject("my_nevra_string") possible_nevra = subject.get_nevra_possibilities() ``` If I want to print all possible names just use: ``` for nevra in possible_nevra: print(nevra.name) ``` Is that sufficient for you?
Jakub, Javier, does this look good to you for rdopkg? (The context in which we discussed this earlier was https://review.rdoproject.org/r/6705)
I've been testing the patch, and it seems to behave differently from the old splitFilename() method. Since it decides different potential nevra options, I don't know which one of them would match the previous behavior. For example: >>> subject = dnf.subject.Subject("bar-9-123a.ia64") >>> possible_nevra = subject.get_nevra_possibilities() >>> for nevra in possible_nevra: ... print("%s %s %s %s %s" % (nevra.name, nevra.epoch, nevra.version, nevra.release, nevra.arch)) Gives me: bar None 9 123a ia64 bar None 9 123a.ia64 None bar-9 None 123a.ia64 None None bar-9-123a None None None ia64 bar-9-123a.ia64 None None None None Also, using an epoch in the filename (1:bar-9-123a.ia64) gave no results. Jakub, what do you think?
From my point of view parse filename is not good idea. You can read rpm header and from rpm you can get information what you request. In dnf you can import rpm into sack and get package object that has all information like name, epoch ... + a lot of more, but additionally you don't need to trust filename format but you will see directly content. All possible forms that we support are: hawkey.FORM_NEVRA, hawkey.FORM_NEVR,hawkey.FORM_NEV, hawkey.FORM_NA, hawkey.FORM_NAME .
I am really sorry, but we don't have a plan to support ENVRA format for parsing and so far we don't have a plan for direct support for parsing of file path to get nevra. As I mentioned above it is possible to use DNF api to parse string into nevra class, but this is all what we can offer at present time.
For those trying to do this with DNF from dnf.subject import Subject import hawkey subject = Subject("libaio-0.3.110-9.fc27.x86_64") nevra = subject.get_nevra_possibilities(forms=hawkey.FORM_NEVRA) for i in nevra: print i.name print i.version print i.epoch print i.release print i.arch
(In reply to Shawn Starr from comment #6) > For those trying to do this with DNF > > from dnf.subject import Subject > import hawkey > > subject = Subject("libaio-0.3.110-9.fc27.x86_64") > nevra = subject.get_nevra_possibilities(forms=hawkey.FORM_NEVRA) > for i in nevra: > print i.name > print i.version > print i.epoch > print i.release > print i.arch Update for python3 print needing (): from dnf.subject import Subject import hawkey subject = Subject("libaio-0.3.110-9.fc27.x86_64") nevra = subject.get_nevra_possibilities(forms=hawkey.FORM_NEVRA) for i in nevra: print(i.name) print(i.version) print(i.epoch) print(i.release) print(i.arch)