This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
fedora-repoquery is a small commandline tool for doing repoqueries of Fedora, EPEL, eln, and Centos Stream package repositories. It wraps dnf repoquery separating the cached repo data under separate repo names for faster cached querying. Repoqueries are frequently used by Fedora developers and users, so a more powerful tool like this is generally useful.
fedora-repoquery (fdrq for short) has been in development for a while, and with the 0.6 release now should be polished enough now to be included in Fedora for broader usage. See the readme file for usage examples.
I am aware of fedrq which is somewhat similar to fedora-repoquery, but has a different design and emphasis. The biggest difference being that fedora-repoquery supports easily querying different OS release versions, and also tells you by default in which specific repo a partcular package lives.
Users will have the benefit of a flexible repoquery tool with which they can check versions of packages etc in different release versions of Fedora, EPEL, Centos Stream, and eln.
Dependencies
Contingency Plan
Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
Contingency deadline: N/A (not a System Wide Change)
Blocks release? N/A (not a System Wide Change), Yes/No
If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.
We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.
Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.
I would really hope that Fedora would have a single, well working and well maintained recommendation for each packaging task. Of course any number of tools can be packaged, used, announced and recommended in other contexts (like devel posts), but if there is a change introducing a new tool, I think Package Maintainer Docs should be updated to recommend that tool for each task it can perform.
This Change is not intended to replace fedrq. fedora-repoquery offers a simple extended UI over dnf repoquery with a few extra features , which some people might prefer. I do welcome feedback from users.
I think of fedora-repoquery (fdrq) as an easy to use tool for quick repoquerying.
I guess a more detailed comparison with fedrq would be interesting.
General Fedora users may well be happy with simple repoquerying with just dnf rq (or maybe the dnf-repo rq wrapper). fedora-repoquery (a wrapper of dnf rq) allows straightforward querying of different releases using conventional dnf query options.
I think an advantage of fedrq is it offers completions of its actions and its opinionated approach to repoquerying: I assume it uses the python dnf bindings. I see it also offers various clones. In a sense fedora-repoquery is simpler it just runs standard dnf repoqueries with appropriate long release repo options.
Anyway I feel a little competition or rather alternatives are useful.
I would be happy if fedrq wants to take any ideas from fedora-repoquery.
I see that fedrq outputs source packages too by default, which surprised me at first.
When querying a particular release, fedora-repoquery only queries the official repos not any locally enabled ones: ie it is primarily designed for pristine OS repoqueries.
In fact before 0.6, fdrq always required a release argument before the query.
One useful feature of fdrq is that it can display the repo timestamps so one knows how up-to-date the queried (mirror) repos are.
Development of fedora-repoquery started almost 3 years ago (so roughly a year before the initial release of fedrq), but the initial 0.1 release was only a year ago: I have been slowly improving it over time. (It was originally inspired or derived from an internal Red Hat tool I have for querying internal RHEL repos - since RHEL splits packages across several repos it useful to know which repo a package lives in.)
Isn’t the entire change proposal a big PR? In other words, why is there a change proposal for introducing a new package to Fedora?
I think you can just have the package reviewed and added to Fedora without submitting a change proposal. Once it has landed you can run some PR on the mailing list, trying to sell it. I believe that’s what Maxwell did for fedrq.
I believe the name of the binary is very unfortunate. The pool of fed prefixed tools is growing. I already have trouble keeping fedrq and fedpkg apart when typing because I use them for the same goal - package maintenance.
You say the emphasis of fdrq is different from fedrq. It looks more like the functionality is extended. Despite both tools being written in different languages, it feels more like the functionality setting them apart should be combined in one tool[1].
I don’t fancy the idea of having both fedrq and fdrq around, both in terms of the names and of the functionality. fd is commonly used in connection with file descriptors or devices, please don’t overload it with “fedora something”.
Both tools seem to fulfill a similar purpose. Have you tried contributing to the other one?
Speaking of contributing: Your tool is implemented in Haskell. Consequently, we cannot expect many contributions, quite opposed to something written in C or Python.
So, while the structural design (separate caches) may be great I"m skeptical whether the other choices are beneficial community-wise.
I was commenting on the short name for the binary. With fedrq already in use, fdrq is to close to distinguish it.
I don’t know. Users and their reasoning are elusive. I myself could imagine needing both at some point. That’s also why I think combining the functionality of both in one tool, would be even more beneficial to the community.
Nope. That’s not making it any better, in my opinion. I’d go with what others suggested: Use the long name and leave any short acronyms to the user’s ~/.bashrc.
Okay, thank you for the useful constructive feedback - tough crowd : - )
I have released version 0.7 which drops the short name and only provides fedora-repoquery, so that should avoid any confusion with fedrq. It is now in the copr repo.
Thank you for clarifying the intent regarding replacing fedrq. Since there is no such intent here, and I already too a look what Package Maintainer Docs say about fedrq, I actually created a pull request there, improving how fedrq is presented.
I do not have any packages in difficult positions in the dependency graph, so I am not a heavy user of this kind of tools. Thus, I am open to suggestions for what could and should be said about this new tool in the Package Maintainer Docs.
Summary
instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.