Created attachment 984965 [details] example code Description of problem: Can you give me a way to find the virtual provides by some search name in the current repository? Attaching my existing dnf api using script that searches packages based on search string but not also for virtual provides available in the same repository. Not sure if this issue belongs to hawkey and if it is please move bug to hawkey component. Thanks.
Hello Parag, does this code cover your use case: dnf.subject.Subject(srch_pat).get_best_query(db.sack) ?
above change still not give me virtual provides. With above code I get some package names trice. see some part of output <snip> libreoffice-langpack-mai libreoffice-langpack-mai libreoffice-langpack-mai libreoffice-langpack-ml libreoffice-langpack-ml libreoffice-langpack-ml libreoffice-langpack-mr libreoffice-langpack-mr <snip> libreoffice-langpack-pl libreoffice-langpack-pl libreoffice-langpack-pt-BR libreoffice-langpack-pt-BR libreoffice-langpack-pt-PT libreoffice-langpack-pt-PT libreoffice-langpack-ro libreoffice-langpack-ro <snip>
Yes, because you are printing just names (I mean "print pkg.name"). The code finds packages that has name matching "srch_pat" together with packages that provide "srch_pat". But it still returns packages. So you just need to expand the provide glob to all existing provides? Like a string "libreoffice-langpack-*" as an input and a list of strings ["libreoffice-langpack-pt_BR"] as the output? I'm not aware of such function now. If that's what you need, can you share the use case please? What will you do with the output then?
e.g. I want to search for all package names available in repository be it real package names or virtual package names for search pattern "libreoffice-langpack-*". Should I get output libreoffice-langpack-pt_BR from dnf search/filter api? Currently, if you check "dnf langinstall pt_BR" will not pick package libreoffice-langpack-pt-BR for installation. Use Case for this: Some brief context, When yum-langpacks written we faced this same problem of no yum api to get virtual provide names. We were 3 maintainers to yum-langpacks and as we could code to have this fixed in yum-langpacks itself we never asked to yum developers for such api. Now why we need to read virtual provides? langpacks plugin reads such available language packages by input locale code like pt_BR, cs, zh_CN, pt_PT. The internal function collects such all packages and searches locale code in rpm package name itself and if found mark that package as a package set for the given input locale code. In fedora before yum-langpacks such packages exists with their own way of naming packages like in this case libreoffice-langpack-pt-BR instead libreoffice-langpack-pt_BR. I think some packages that provides langpacks added then virtual provides when yum-langpacks got developed but then it never worked for "yum langinfo pt_BR" command. I then requested FPC with new naming guidelines for such packages where real package name ends with glibc locale code. See https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28langpacks.29 page. This took almost one year to appear now in official fedora guidelines. I now reported bug 1182110 and based on its assignee feedback reported this bug. Actually I will like to always prefer such packages to have real name to follow langpacks naming guidelines but just want to check you guys if any dnf api can help me. Thanks.
(In reply to Parag from comment #4) > e.g. I want to search for all package names available in repository be it > real package names or virtual package names for search pattern > "libreoffice-langpack-*". Should I get output libreoffice-langpack-pt_BR > from dnf search/filter api? No, you'll get a package called "libreoffice-langpack-pt-BR": dnf.subject.Subject("libreoffice-langpack-pt-BR").get_best_query(db.sack) returns a package instance called "libreoffice-langpack-pt-BR"; dnf.subject.Subject("libreoffice-langpack-pt_BR").get_best_query(db.sack) also returns a package instance called "libreoffice-langpack-pt-BR" (assuming libreoffice-langpack-pt-BR provides libreoffice-langpack-pt_BR); dnf.subject.Subject("libreoffice-langpack-*").get_best_query(db.sack) also returns a package instance called "libreoffice-langpack-pt-BR" (twice) plus some other packages matching the pattern. I believe that's what you need.
What need to be done to get using dnf.subject.Subject("libreoffice-langpack-*").get_best_query(db.sack) output as libreoffice-langpack-pt-BR and libreoffice-langpack-pt_BR ? If I will get both these names the internal mapping function for given input language pt_BR will discard libreoffice-langpack-pt-BR name and pick only libreoffice-langpack-pt_BR name to install.
To sum up a discussion on IRC: The use case is that langpacks want to print the *provide* name when "dnf langinfo" command is executed regardless the fact that man pages say that "This command allows user to check which packages will get installed when the given input language support is installed.". The rationale is that user can install the package even if it's specified by a provide name. Currently, it would be possible to print *package* names when "dnf langinfo" command is executed even for packages found by *provide* globs via the code mentioned above. But there is no direct way to expand provide globs via DNF API now. We may consider adding such function.
Parag, BTW, I recommend you to replace ".filter(name__glob=srchpat)" with "dnf.subject.Subject(srchpat)" in your code in the meantime before we decide. I believe it's better than nothing.
Parag, the glob provides search is implemented in Selectors only. Try: `dnf.subject.Subject(srchpat).get_best_selector(db.sack)`. This will return a package that provides that pattern or if none exist it will search by name then.
Thanks. I used s.matches() and found following only one entry for pt_BR or pt-BR in output. I actually wanted "libreoffice-langpack-pt_BR" in the output. libreoffice-langpack-pt-BR repoquery shows me this $ sudo dnf repoquery --provides libreoffice-langpack-pt-BR libreoffice-langpack-pt_BR libreoffice-langpack-pt-BR = 1:4.3.5.2-12.fc21 libreoffice-langpack-pt-BR(x86-64) = 1:4.3.5.2-12.fc21
Yes, that's the expected result. I've already said that the function you need is missing and it must be added. We just thought that the "Subject.get_best_selector" way could be useful for you in the meantime before we add the function that you need.
Jan, Parag is not asking for "hawkey.Query.filter: support provides__glob". He doesn't want a *package* for given provide name. He wants the provide name specification to be expanded to all existing *provide* names. I.e.: he wants "libreoffice-langpack-*" to be expanded to "libreoffice-langpack-pt_BR".
Yes. I need to query using dnf to find virtual package names (including real package names).
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
I have changed the langpacks code in 0.9.0 release and managed with dnf.subject.Subject("package-<local_code>").get_best_query(db.sack) This is giving me the real package names. If in the repository package-<locale_code> is not a real package then above call will return the real package name. Here assumption is that whatever be real package is, it will be virtual providing "package-<locale_code>". For this implementation I asked few packages who have missing virtual provides to add them and now all is working fine for langpacks package selection ;-) I now don't need any further modifications in hawkey code.
Congratulations that you managed to convince the maintainers to rename the packages! :-) Anyway I think that this future might be handy to someone. But since the implementation is difficult, let's wait for them... :)
*** This bug has been marked as a duplicate of bug 879233 ***