Created attachment 520474 [details] Fix Description of problem: rpm uses the query format exactly as given, while repoquery adds a trailing newline after each package (the "print" statements in runQuery). Thus, an RPM user who passes a query format ending in \n to repoquery will get extra blank lines. repoquery should compensate by removing a trailing newline from the specified query format. Alternatively, it could stop adding the trailing newline, but this would require larger code changes and break existing users who had gotten away without specifying a trailing newline. Version-Release number of selected component (if applicable): yum-utils-1.1.31-2.fc15 How reproducible: Always Steps to Reproduce: 1. repoquery -qa --qf '%{NAME}\n' 'yum-plugin-*' Actual results (with showdupesfromrepos on): yum-plugin-aliases yum-plugin-aliases yum-plugin-aliases yum-plugin-auto-update-debug-info yum-plugin-auto-update-debug-info yum-plugin-auto-update-debug-info [...] Expected results: yum-plugin-aliases yum-plugin-aliases yum-plugin-aliases yum-plugin-auto-update-debug-info yum-plugin-auto-update-debug-info yum-plugin-auto-update-debug-info [...]
We were asked about this before and the answer then is the same as now. No. Just b/c rpm made some bad choices a long time ago is no reason to continue it in repoquery now.
I see the previous bugs now... I missed them before because they did not have enough keywords in the summary. *** This bug has been marked as a duplicate of bug 550027 ***
Actually my proposal is different from the previous bugs: repoquery --qf '%{NAME}\n' would remove the \n, leaving only repoquery's mandatory newline, but repoquery --qf '%{NAME}' would work as it does now. Are you still not interested? Are there actually programs passing \n that will break if they get one fewer blank line than before? (In reply to bug 550027 comment #3) > While the queryformat strings of rpm and repoquery are > similar, there are numerous incompatibilities between them, you can't expect to > copy-paste between rpm and repoquery query formats anyway. Sure, the advanced features are incompatible, but it's a pity not to let simple things like --qf '%{NAME}\n' work the same way in both tools.
We can't possibly know what scripts users have built on top of repoquery, it's been out there long enough chances are somebody is relying on the current behavior with extra newline with trailing \n when explicitly added. I suppose what we could do is add a --no-newline style switch which would then behave like rpm's queryformat.
I don't think it is worth it and it just sets us up for having to provide other compatibilities with rpmq. they are not the same syntax, they are similar - nothing else.
(In reply to comment #4) > I suppose what we could do is add a --no-newline style switch which would then > behave like rpm's queryformat. That would not reduce the number of details a user has to remember to successfully port an rpmq command line to repoquery, so I wouldn't bother. More generally, one could add an --rpmq switch that would activate all present and future tweaks for better rpmq compatibility and caution users that behavior differences between rpmq and "repoquery --rpmq" may go away at any time and should not be relied on. (In reply to comment #5) > and it just sets us up for having to provide other > compatibilities with rpmq. Not necessarily; if there are good arguments not to do that, you can make them at that time. > they are not the same syntax, they are similar - nothing else. So you added -q as an ignored option, but since then have backed away from the goal of compatibility with rpmq in simple cases? It's disappointing to have an option with the same name and a limited but useful range of values that produce the same behavior in both programs, except for this newline issue.
So, in theory, we could do this: diff --git a/repoquery.py b/repoquery.py index 0138251..24b899a 100755 --- a/repoquery.py +++ b/repoquery.py @@ -1226,6 +1226,9 @@ def main(args): print parser.format_help() sys.exit(1) + if opts.queryformat and opts.queryformat[-2:] == '\\n': + opts.queryformat = opts.queryformat[:-2] + pkgops = [] sackops = [] archlist = None ...which would have the downside of breaking compatibility, but hopefully in a way not many people cared about ... and would be localized. I'm far from sure it's a good idea though.
Re comment #7: that's what my patch does, and we were discussing the implications in comment #3 and comment #4.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping