[aur-dev] [PATCH] pkgsubmit.php: Parse .SRCINFO metadata

[Dan McGee]

On Sat, Mar 16, 2013 at 5:38 PM, Alexander Griesbaum <agrsbm at gmail.com> wrote:
> On Tue, Mar 5, 2013 at 4:02 PM, Lukas Fleischer
> <archlinux at cryptocrack.de> wrote:
>> On Tue, Mar 05, 2013 at 03:46:55PM +0100, Alexander Griesbaum wrote:
>>>
>>> On Mar 5, 2013, at 1:37 PM, Lukas Fleischer wrote:
>>>
>>> > +           foreach (explode("\n", $srcinfo_raw) as $line) {
>>> > +                   if ($line[0] = '#') {
>>> > +                           continue;
>>> > +                   }
>>> > +                   list($key, $value) = explode(' = ', $line, 2);
>>>
>>> Hey, it's me again.
>>>
>>> I think it wouldn't be bad to process the file in the same way as the PKGBUILD is processed[1]:
>>>
>>> <snip>
>>> foreach (explode("\n", $pkgbuild_raw) as $line) {
>>> $line = trim($line);
>>> # Remove comments
>>> $line = preg_replace('/\s*#.*/', '', $line);
>>> <snip>
>>>
>>> I didn't look deep into the whole code and maybe you've got good reasons to change that procedure so please ignore my mail if you like. Though it may be unnecessairy to change the whole procedure, I really recommend to add the trim() line for more comfort.
>>
>> The difference between PKGBUILD and .SRCINFO parsing is that we want
>> .SRCINFO metadata to be as simple to parse as possible and therefore
>> don't support quoting etc.
>>
>> This implies that there will only be full-line comments since otherwise,
>> there would be no way to add a package description that contains a pound
>> sign ("#").
>>
>> The trim() line is something I am not sure about. libalpm doesn't seem
>> to do this when parsing .PKGINFO files but I also can't imagine any use
>> case where leading/trailing space would come in handy...
>
> Hey.
>
> Thanks a lot for your explanation.
>
> trim():
> It isn't really handy, right. But I still think it should be handled
> the same way as the PKGBUILD is. To have the trim() there would be
> more.. let's say... tolerant?

Tolerant of what besides badly formed input data? This is machine
generated info that happens to be human readable. It does not make
sense to be tolerant- the spec is as simple as possible. Find the '=',
split, then you have your info.

makepkg will never generate data that needs to be trimmed. It would
seem silly that when coming up with a new file format, you don't
follow the precedent and also make your requirements as strict as
possible since you have no backward compatibility problem here.

-Dan