Re: rpm -q --specfile ( --provides | --conflicts ) bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:
%package  subpackage
Provides: %{name} = 1-a
Provides: OK_subpackage_Provide = %{version}-%{release}

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 :
$ rpm -q --specfile SPECS/test-bug.spec \
    --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n'  \
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

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 :
$ rpm -q --specfile avahi.spec  \
   --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n'  \
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

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:
$  rpm -q --specfile SPECS/test-bug.spec \
     --qf '%{NAME} %{EPOCH} %{VERSION} %{RELEASE} %{ARCH}\n' \
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
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 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 mailing list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux