Bug#594435: Quoted strings in pin specifications do not work
> Is Data guaranteed to be non-empty here? If not, you should check that
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 <email@example.com>:
> 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