rpm -q --specfile ( --provides | --conflicts ) bug
Jason Vas Dias
jason.vas.dias at gmail.com
Mon Sep 15 16:46:03 UTC 2014
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 at laiskiainen.org> 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 at lists.rpm.org
>> http://lists.rpm.org/mailman/listinfo/rpm-list
>>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
More information about the Rpm-list
mailing list