[csw-devel] [PATCH] checkpkg: allow collection of obsoletion info

[Maciej Bliziński]

2011/3/27 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Maciej Bliziński's message of Sun Mar 27 04:18:42 -0400 2011:
>
>> I've recently learned a Python idiom for opening files:
>>
>> with open(obsoleted_by_path, "r") as fd:
>>   indented block
>>   using fd
>
> Ah!  Very ruby-esque, I like it.  The same thing in Ruby would be:
>
> File.open("/path/to/file", "r") do |file|
>  file.each_line do |line|
>    ...
>  end
> end
>
> (I'm one of the folks that likes the 'end' block markers as I find
> they improve readability.)

Nothing prevents you from using them in Python:

end = None # define a name

for i in range(4):
  for j in range(4):
    print i, j
  end
end


>> fd is unavailable outside that block
>
> Exactly the way it works in ruby too.  This is much nicer for many of
> the typical file processing tasks that are common in code.
>
>> I expect that some packages might contain a file with bad syntax, e.g.
>> 3 fields or 1 field.
>
> Yes, a good point.  I'm only using the first two fields, but there is
> a package description for the package that obsoletes the package too.
> Not sure it's much use in the tests though.  We could forseeably
> change the description of a package in the future while not releasing
> the updated _stub packages for example.  Thus, of the line with
> format:
>
> CSWfoo foo - The foo package is great
>
> We only care about the first two white space separated fields.

Agreed.

>>   if 2 != len(fields):
>
> I prefer len(fields) != 2.  Is there a reason you prefer the ordering
> above?  If it's the more common ordering throughout the code, I'll use
> it for consistency.

If it was C, I would argue that 2 != len(fields) is better.  In
Python, use what you feel is more readable.

Since we allow >2 fields: if len(fields) < 2: (...)

>> Or even better:
>> return {
>>   "syntax": obsoleted_syntax_ok,
>>   "by": obsoleted_by,
>> }
>
> I like this better too.
>
>> Next steps should be:
>>
>> - add a dict item around lib/python/package_stats.py line 500 (you
>> could add a tuple, or transform it into a dictionary, or use
>> whatever form that you think will be convenient to use later on; I
>> like dictionaries because they tend to be self-descriptive)
>
> I was looking at this last night but couldn't make the new info be
> displayed in the output of checkpkg_inspect_stats.py -p...
>
>> - since you're changing the data format, increment
>> PACKAGE_STATS_VERSION in package_stats.py (line 25)
>
> Ok, didn't catch that last night.
>
>> - use the new data structure in a check
>
> I think the first thing I'll do is ensure _stub when obsoleted by
> syntax is ok and the list isn't empty.  There are many other checks
> that can focus on this new data.  A list that isn't empty but fails
> the syntax check would be one such test.

You could also check package description: if it's a _stub, it needs to
declare that in the description; if it declares that in the
description, it needs to be a _stub.

> Updated patch attached.

I wouldn't mind inline patches, it would let me skip downloading, and
allow commenting inline.

Maciej