Hello Michael,

On 10/28/14, 12:00 PM, Michael Vogt wrote:
> On Wed, Oct 22, 2014 at 02:08:19PM +0200, Kai Storbeck wrote:
>> Dear Maintainer,
> Hi Kai,
> 
> thanks for your bugreport.

Appreciated. Thanks for getting back to it!

>> I tried adding this package to the package-blacklist:
>>
>>      libstdc++6
>>
>> This will fail, as it is an invalid regular expression:
> [..]
>>>   File "/usr/lib/python2.7/re.py", line 242, in _compile
>>>     raise error, v # invalid expression
>>> sre_constants.error: multiple repeat
>>
>> (this is on wheezy)
>>
>>
>> Is this intentional, or is this a bug?
> 
> This is sort-of intentional but I think you raise a interessting
> usability issue here. The blacklist/whitelist consists of regular
> expressions but that is actually not super user friendly as its not
> obvious and they are also hard to use compared to something like
> glob/fnmatch style matching (or plain packagenames). I can't change
> this easily without breaking existing setups though. 

Well, it was a basic stringcompare in squeeze. We're using a mix of
squeeze and wheezy, and the blacklist is maintained through a puppet
recipe templating the blacklist value.

> So I think better documenting it is the first step.
> 
> It could simply use it as a plain string if the regexp fails and
> display a warning.

I think that would certainly benefit me. I'm working around the problem
by writing ^libstdc.*.

Perhaps aborting due to invalid input is the best solution, but I might
suggest a more friendly warning without a traceback.



> Or I could add a new
> Unattended-Upgrade::Package-Blacklist-Plain list for non-regexp
> content (it really should be the other way around,
> Unattended-Upgrade::Package-Blacklist-Regex and
> Unattended-Upgrade::Package-Blacklist would be plain but that is
> tricky due to the compatibility concerns I outlined earlier.

I doubt you need another setting. The current list is quite fine. If I
would have been at the design board, I would suggest parsing strings
starting and ending with slashes  (e.g.: /foo/) to parse as a regexp,
and strings without slashes as real strings.

But I grew up in a perl world and find python's regexps a but
boilerplatey  having to compile them explicitly.


Regards,
Kai Storbeck

-- 
Systeembeheer XS4ALL Internet bv
Internet: www.xs4all.nl
Contact: www.xs4all.nl/contact

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to