Bug 734259 - repoquery should remove trailing newline from --qf for RPM compatibility
repoquery should remove trailing newline from --qf for RPM compatibility
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2011-08-29 18:06 EDT by Matt McCutchen
Modified: 2014-01-21 18:19 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-07 16:04:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix (599 bytes, patch)
2011-08-29 18:06 EDT, Matt McCutchen
no flags Details | Diff

  None (edit)
Description Matt McCutchen 2011-08-29 18:06:35 EDT
Created attachment 520474 [details]

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):

How reproducible:

Steps to Reproduce:
1. repoquery -qa --qf '%{NAME}\n' 'yum-plugin-*'
Actual results (with showdupesfromrepos on):






Expected results:
Comment 1 seth vidal 2011-08-29 23:44:53 EDT
We were asked about this before and the answer then is the same as now.


Just b/c rpm made some bad choices a long time ago is no reason to continue it in repoquery now.
Comment 2 Matt McCutchen 2011-08-29 23:55:46 EDT
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 ***
Comment 3 Matt McCutchen 2011-08-30 00:04:29 EDT
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.
Comment 4 Panu Matilainen 2011-08-30 01:14:33 EDT
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.
Comment 5 seth vidal 2011-08-30 07:44:12 EDT
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.
Comment 6 Matt McCutchen 2011-08-30 12:59:11 EDT
(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.
Comment 7 James Antill 2011-08-30 16:02:26 EDT
 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()
+    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.
Comment 8 Matt McCutchen 2011-08-30 16:11:33 EDT
Re comment #7: that's what my patch does, and we were discussing the implications in comment #3 and comment #4.
Comment 9 Fedora End Of Life 2012-08-07 16:04:36 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.