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

Fri Sep 12 16:34:32 UTC 2014

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 at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>