Much Thanks Panu for your informative reply , which exposed my misunderstanding of sub-packages & %{name} . Thanks for granting Trac ticket creation privilege to my userid - I will now raise a bug about rpm-4.12.rc1 not emitting the sub-package lines . I think I've found another issue , with both 4.8.0 and 4.12.rc1 : When a Provides: / Conflicts: / Obsoletes: tag (Capability specification) is defined with no whitespace around the operator, RPM is not separating the operator from the provide name : $ rpm --version ; rpm -q rpm RPM version 4.8.0 rpm-4.8.0-32.el6.x86_64 $ cat /tmp/test.spec name: test version: 1 release: 2 license: GPL summary: test Provides: test-provide=1.2.3-0 %description %{summary} %changelog * Mon Sep 15 2014 JVD - created. $ /bin/rpm -q --specfile /tmp/test.spec \ --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH} @\{ [ %{PROVIDENAME} %{PROVIDEFLAGS} %{PROVIDEVERSION} ; ] \}@ @\{ [ %{CONFLICTNAME} %{CONFLICTFLAGS} %{CONFLICTVERSION} ; ] \}@ @\{ [ %{OBSOLETENAME} %{OBSOLETEFLAGS} %{OBSOLETEVERSION} ; ] \}@ \n' test (none) 1 2 x86_64 @{ test-provide=1.2.3-0 0 ; }@ @{ }@ @{ }@ As you can see, the whole string 'test-provide=1.2.3-0' is being emitted as the PROVIDENAME , with no complaint that it contains an '=', which I believe is NOT allowed in version or release strings ? rpm should have emitted: test (none) 1 2 x86_64 @{ test-provide 8 1.2.3-0 ; }@ @{ }@ @{ }@ . rpm-4.12.rc1 has the same problem: $ /usr/local/bin/rpm -q --specfile /tmp/test.spec --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH} @\{ [ %{PROVIDENAME} %{PROVIDEFLAGS} %{PROVIDEVERSION} ; ] \}@ @\{ [ %{CONFLICTNAME} %{CONFLICTFLAGS} %{CONFLICTVERSION} ; ] \}@ > test (none) 1 2 x86_64 @{ test-provide=1.2.3-0 0 ; }@ @{ }@ @{ }@ $ rpm --version RPM version 4.12.0-rc1 Surely rpm should mention that it has defined a provide with an invalid name ? Are capability specifications of the form ' <cap_name> { = | == | >= | > | <= | < } <cap_version>' meant to REQUIRE whitespace between the operator and name ? Incidentally, if I try to include a line like : 'Version: 1=0' in a specfile, RPM rightly complains: error: line 2: Illegal char '=' in: version: 1=0 The same goes for names: 'Name: test=1' error: line 1: Illegal char '=' in: name: test=1 So why does RPM think a string containing '=' could possibly be a capability name or version ? The --provides output does emit 'test-provide=1.2.3-0' but it is impossible to tell whether that is a provide name (I'd guess it is) or a concatenated provide name + provide op + provide version (which I believe it should be). Where is it defined that the capability operator must be surrounded by whitespace to be recognized ? Is this a bug ? Shall I raise one about it ? Thanks & Regards, Jason On 9/12/14, Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> wrote: > On 09/12/2014 06:16 PM, Jason Vas Dias wrote: >> Good day - >> >> There appears to be a bug with the --specfile query option . >> I'm using it to list the sub-packages that would be built by building >> from a spec file, and to determine which sub-packages provide which >> Provides: . >> >> This normally works OK - the Provides or Conflicts of each sub-package >> are listed after each sub-package line (with RPM 4.8.0, not 4.12+ - >> see below) . >> >> However, there is an issue when Provides: or Conflicts: tags of >> sub-package use >> the global '%{name}' macro ; the expansion of %{name} in a sub-package is >> NOT >> being expanded into the sub-package name, but into the main package name. >> >> This is illustrated by the following query done on the attached >> test-bug.spec file, >> which says: >> <quote> >> %package subpackage >> ... >> Provides: %{name} = 1-a >> Provides: OK_subpackage_Provide = %{version}-%{release} >> </quote> >> >> So when I query the provides of this test-bug.spec with RPM 4.8.0 >> (from RHEL-6.4's rpm-4.8.0-32.el6.x86_64 package) , with : >> <quote> >> $ rpm -q --specfile SPECS/test-bug.spec \ >> --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n' \ >> --provides >> test-bug (none) 1 a x86_64 >> test-bug = 1-a >> test-bug-subpackage (none) 2 b x86_64 >> test-bug = 1-a >> OK_subpackage_Provide = 2-b >> </quote> >> >> test-bug-subpackage's Provide '%{name} = 1-a' is being expanded to >> 'test-bug =1-a' , NOT to 'test-bug-subpackage = 1-a' , >> which is the opposite of what I'd expect. >> >> However the '%{version}-%{release}' in test-bug-subpackage's Provide: >> 'OK_subpackage_Provide = %{version}-%{release}' ARE correctly >> expanded into the version & release of the sub-package, not of the >> main package, as I would expect. >> >> So the problem appears to happen only for the '%{name}' macro . > > The name of the problem here is incorrect expectations. Its not a spec > parser bug (much less spec query), but an ancient implementation detail > that can never be changed because thousands and thousands spec files > actually rely on it. > > %{name}, %{version} etc are all simply defined from the contents of > corresponding tag and if there are multiple tags, the last one wins. > Because subpackage name is specified with a different syntax, %{name} > never gets redefined. However subpackage version, group etc are all > specified with their own Version: etc tags, which causes the > corresponding tag macros to be redefined. There is nothing "intelligent" > like per-package context present here, its just plain dumb spec tag > processing order. > >> This can be an issue with real-world RPMs also, as evidenced by trying >> to determine the Conflicts: of avahi sub-packages by querying the >> avahi.spec >> file from avahi-0.6.25-12.el6_5.1.src.rpm : >> <quote> >> $ rpm -q --specfile avahi.spec \ >> --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n' \ >> --conflicts >> avahi (none) 0.6.25 12.el6.1 x86_64 >> avahi-tools (none) 0.6.25 12.el6.1 x86_64 >> avahi-ui-tools (none) 0.6.25 12.el6.1 x86_64 >> avahi-glib (none) 0.6.25 12.el6.1 x86_64 >> avahi < 0.6.25-12.el6.1 >> avahi > 0.6.25-12.el6.1 >> avahi-glib-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-gobject (none) 0.6.25 12.el6.1 x86_64 >> avahi-gobject-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-ui (none) 0.6.25 12.el6.1 x86_64 >> avahi-ui-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-qt3 (none) 0.6.25 12.el6.1 x86_64 >> avahi < 0.6.25-12.el6.1 >> avahi > 0.6.25-12.el6.1 >> avahi-qt3-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-qt4 (none) 0.6.25 12.el6.1 x86_64 >> avahi < 0.6.25-12.el6.1 >> avahi > 0.6.25-12.el6.1 >> avahi-qt4-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-libs (none) 0.6.25 12.el6.1 x86_64 >> avahi-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-compat-howl (none) 0.6.25 12.el6.1 x86_64 >> avahi < 0.6.25-12.el6.1 >> avahi > 0.6.25-12.el6.1 >> avahi-compat-howl-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-compat-libdns_sd (none) 0.6.25 12.el6.1 x86_64 >> avahi < 0.6.25-12.el6.1 >> avahi > 0.6.25-12.el6.1 >> avahi-compat-libdns_sd-devel (none) 0.6.25 12.el6.1 x86_64 >> avahi-autoipd (none) 0.6.25 12.el6.1 x86_64 >> avahi-dnsconfd (none) 0.6.25 12.el6.1 x86_64 >> avahi-debuginfo (none) 0.6.25 12.el6.1 x86_64 >> </quote> >> >> Every sub-package in avahi.spec is specifying : >> Conflicts: %{name} < %{version}-%{release} >> Conflicts: %{name} > %{version}-%{release} >> >> I'm guessing that the packager's intent here was to say that >> the version of each sub-package conflicts with every other >> version of that sub-package (which seems to me somewhat >> redundant, since only one version of a sub-package can be >> installed at one time) . But rpm -q --specfile is reporting >> that each subpackage conflicts with any version of the avahi >> main package with a different version. > > That is not a spec query quirk/bug, its what will end up in the actual > packages when built. One can only hope that is what the packager > actually expected :) > >> >> I tried this with the latest RPM version 4.12.0-rc1 , with the same >> results >> with respect to the sub-package %name expansion problem . >> But this version of RPM also appears to have another bug: it is not >> emitting >> the sub-package version lines , as RPM 4.8.0 does . With RPM 4.12-rc1, I >> get: >> <quote> >> $ rpm -q --specfile SPECS/test-bug.spec \ >> --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n' \ >> --provides >> test-bug = 1-a >> OK_subpackage_Provide = 2-b >> test-bug = 1-a >> $ rpm -q --specfile SPECS/test-bug.spec --provides >> test-bug = 1-a >> OK_subpackage_Provide = 2-b >> test-bug = 1-a >> </quote> >> ie. RPM 4.12+ with the -q --specfile option no longer emits lines for >> each >> sub-package if also given a --provides or --conflicts option . >> This is even worse, because there is now no way to tell which sub-package >> provides which Provides: or Conflicts: tag with RPM 4.12 and -q --specfile >> . > > Rpm 4.12 rc not emitting those self-provides is indeed a regression, > thanks for reporting. > >> >> Owing to these bugs, it appears to be impossible to use rpm -q >> --specfile to >> reliably parse spec files, and one is left having to write one's own spec >> file >> parser , which I believe it was the intention of adding the --specfile >> option >> to obviate . > > Only the 4.12 issue is an actual bug. >> >> I'd like to raise these issues as tickets in rpm.org Trac, but I do not >> have >> 'Create Ticket' privilege (my userid there is 'JVD' ) . If granted >> permission >> I would do so. > > I've added you to the "bugreporters" group so you should now be able to > create tickets there. > >> >> Any thoughts / suggestions on this issue would gratefully received. >> >> Thanks & Regards, >> Jason Vas Dias . >> >> >> >> _______________________________________________ >> Rpm-list mailing list >> Rpm-list@xxxxxxxxxxxxx >> http://lists.rpm.org/mailman/listinfo/rpm-list >> > > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxxxxx > http://lists.rpm.org/mailman/listinfo/rpm-list > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list