On Sat, Mar 16, 2013 at 5:38 PM, Alexander Griesbaum <[email protected]> wrote: > On Tue, Mar 5, 2013 at 4:02 PM, Lukas Fleischer > <[email protected]> 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
