Bug#594435: Quoted strings in pin specifications do not work
> Is Data guaranteed to be non-empty here? If not, you should check that
> first.
It is as the first real line of the method checks for Data.length() < 1
and otherwise exits, so Data is at least one char long.
You can still do a silly Pin: origin "
which should maybe be catched as not allowed to match an
empty string, but even if detected it can't be expressed with a
error message as the parser seems to be too dumb for it…
2010/8/30 Julian Andres Klode <jak@debian.org>:
> On Mo, 2010-08-30 at 11:34 +0200, David Kalnischkies wrote:
>> > I personally do not want quoting here, as it just complicates parsing
>> > and breaks backwards compatibility. The documentation could state
>> > explicitly that quotes are not supported; but this is purely a
>> > documentation issue, and thus minor (it may also break translations of
>> > the manpage).
>>
>> I don't get the complicated parser argument, how could a single char
>> increase the complexity of a parser - especially as the empty string
>> needs to be represented somehow anyway…
>> And compatibility? Its long ago that i saw a hostname starting with "…
>> Or do we need to maintain compatibilty with this bugs as users have non
>> working rules in their preferences file because of this bug?
> Well, for origin Pins alone this does not apply. I was talking about
> allowing quoted strings everywhere in preferences files. And yes, a
> hostname can not contain quotes at all, at least if you want to follow
> RFC 3986.
>
> Of course, if you only add quotes to origins, you break nothing. But as
> a hostname can not contain spaces, having quotes there is useless; and
> it still gives you the assumption that you can use quotes every.
but a hostname can be empty in which case the preferences manpage says
Pin: origin "" will match.
Pin: release a= on the other hand will not work and is also not
advertised this way in the manpage nor in the apt-cache policy output.
I think it is just tempting to write "hostname" if you have an example in
that way, even if the hostname in this example is empty.
The rule "<hostname or empty>" feels more natural than <hostname or "">.
Especially if no error is given for wrong syntax…
The space argument is in so far complicated as Label and Co could include
spaces and Pin: release l="some label" is not supported in any way…
>> Attached is the overly complicated patch to fix it by implementing option 2 -
>> option 1 would only differ a bit in the first if-else block and would need
>> a bit too much handwork on the po files for my taste…
> Any reason why you break/remove pattern matching in your patch? I think
> Pin: origin *debian.org
> Pin: origin /.*debian.org/
> can be really useful (that's why I wrote it).
In which way is it broken?
I just removed the first invocation as matching doesn't need to be checked
twice if the entry matches, thats all, the pattern magic still happens in the
return line…
Best regards
David Kalnischkies
Reply to: