[Rpm-maint] PATCH: Accessing file and policy lists from python (and C)

[Alec Leamas]

On 09/27/2012 09:27 AM, Panu Matilainen wrote:
> On 09/21/2012 08:13 PM, Alec Leamas wrote:
>> On 09/21/2012 01:42 PM, Panu Matilainen wrote:
>>> On 09/21/2012 01:59 PM, Alec Leamas wrote:
>>>> On 09/21/2012 07:02 AM, Panu Matilainen wrote:
>>>>> On 09/15/2012 05:47 PM, Alec Leamas wrote:
>>>>>> When rpm-build parses the specfile, it also parses the file list and
>>>>>> (nowadays?) also the policy. These are stored in specPackage objects
>>>>>> attached to the spec. However, these items are not visible on the
>>>>>> rpm.specPkg interface, neither from C nor from python.
>>>>>>
>>>>>> Is there a particular reason these items aren't visible?
>>>>>
>>>>> It's simply because access to the flat, unpopulated file list doesn't
>>>>> seem useful at all to me, and not exposing something means not having
>>>>> to commit to an interface for it.
>>>>>
>>>>>> I have som pronlems with this related to the fedora-review tool [1],
>>>>>> which basically forces us to use some hand-crafted specfile 
>>>>>> parsing ,
>>>>>> since the file lists are needed. I would certainly prefer using
>>>>>> rpmlib's
>>>>>> own parsing for that. However, then external access to the fields
>>>>>> fileList, fileFile and policyList is needed. The enclosed patch
>>>>>> arranges
>>>>>> this.
>>>>>
>>>>> I'm curious: what exactly are you doing / planning to do with the 
>>>>> file
>>>>> list?
>>>>>
>>>>>
>>>> [cut, lot's of]
>>>>
>>>> It's fedora-review... we are  reviewing the packages, comparing the
>>>> raw, unexpanded list with various guidelines sections.
>>>
>>> I guessed that much, but what kinds of things exactly? I'm mostly just
>>> curious, but also wanting to see if there's something that rpm could
>>> help with.
>>
>> Just an example, a snippet from current tests below. There are more of
>> these, but I doubt it makes sense to paste it here.
>>
>> Yes, this is released  code. But the I would very much prefer to use
>> rpm's parsing instead of the hand-crafted parser used today.
>>
>>
>> _init__(self, base):
>>          GenericCheckBase.__init__(self, base)
>>          self.url = 'http://fedoraproject.org/wiki/' \
>>                     'Packaging/Guidelines#Configuration_files'
>>          self.text = '%config files are marked noreplace or the 
>> reason' \
>>                      ' is justified.'
>>          self.automatic = True
>>          self.type = 'MUST'
>>
>>      def run(self):
>>          rc = self.NA
>>          extra = ''
>>          for pkg in self.spec.packages():
>>              for line in self.spec.get_files(pkg):
>>                  if line.startswith('%config'):
>>                      if not line.startswith('%config(noreplace)'):
>>                          extra += line
>>                      else:
>>                          rc = self.PASS
>>          self.set_passed(self.FAIL if extra else rc, extra)
>>
>
> Thanks, also found the other checks in fedora-review now, which are 
> more or less what I expected to see, just wanted to be sure you didn't 
> have some use-case I couldn't imagine at all.
>
> The "problem" with these kind of checks is that they only cover very 
> limited ground and will miss eg anything that goes in through "%files 
> -f <manifest>" etc, which can be a lot. Anyway, what I suppose you'd 
> *really* want (rather than the flat file list) is the parsed result of 
> all those directory modes, config & flags etc. Which of course is 
> available through the package once its built... but rpm itself doesn't 
> bother parsing the file lists before the package has been built, as 
> the entire file list or parts of it can be generated as a part of the 
> build.
> And this is basically why the flat file list from spec is not 
> currently exported: its simply not all that useful.
>
> That said, I dont see much harm in exporting it either, eg through 
> rpmSpecGetSection().
>
>     - Panu -

Updated patch at https://bugzilla.redhat.com/show_bug.cgi?id=857653:
- Return plain string
- SIngle function specPkgGetSection similar to specGetSection.