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

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

 



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




[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