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
