[aur-dev] [PATCH] pkgsubmit.php: Parse .SRCINFO metadata
This allows for adding a metadata file called ".SRCINFO" to source tarballs to overwrite specific PKGBUILD fields. .SRCINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names: * pkgname * pkgver * pkgdesc * url * license * depend Multiple "depend" lines can be specified to add multiple dependencies. This format closely matches the .PKGINFO format that is used for binary packages in pacman/libalpm. It can be extended by field name prefixes or sections to support split packages later. Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- web/html/pkgsubmit.php | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/web/html/pkgsubmit.php b/web/html/pkgsubmit.php index d9bb6bc..4c14be4 100644 --- a/web/html/pkgsubmit.php +++ b/web/html/pkgsubmit.php @@ -81,8 +81,8 @@ if ($uid): if (!$error) { $tar = new Archive_Tar($_FILES['pfile']['tmp_name']); - # Extract PKGBUILD into a string - $pkgbuild_raw = ''; + # Extract PKGBUILD and .SRCINFO into a string + $pkgbuild_raw = $srcinfo_raw = ''; $dircount = 0; foreach ($tar->listContent() as $tar_file) { if ($tar_file['typeflag'] == 0) { @@ -93,6 +93,9 @@ if ($uid): elseif (substr($tar_file['filename'], -9) == '/PKGBUILD') { $pkgbuild_raw = $tar->extractInString($tar_file['filename']); } + elseif (substr($tar_file['filename'], -9) == '/.SRCINFO') { + $srcinfo_raw = $tar->extractInString($tar_file['filename']); + } } elseif ($tar_file['typeflag'] == 5) { if (substr_count($tar_file['filename'], "/") > 1) { @@ -254,6 +257,31 @@ if ($uid): } } + # Parse .SRCINFO and overwrite PKGBUILD fields accordingly + unset($pkg_version); + $depends = array(); + foreach (explode("\n", $srcinfo_raw) as $line) { + if ($line[0] = '#') { + continue; + } + list($key, $value) = explode(' = ', $line, 2); + + switch ($key) { + case 'pkgname': + case 'pkgdesc': + case 'url': + case 'license': + $new_pkgbuild[$key] = $value; + break; + case 'pkgver': + $pkg_version = $value; + break; + case 'depend': + $depends[] = $value; + break; + } + } + # Validate package name if (!$error) { $pkg_name = $new_pkgbuild['pkgname']; @@ -266,7 +294,7 @@ if ($uid): } # Determine the full package version with epoch - if (!$error) { + if (!$error && !isset($pkg_version)) { if (isset($new_pkgbuild['epoch']) && (int)$new_pkgbuild['epoch'] > 0) { $pkg_version = sprintf('%d:%s-%s', $new_pkgbuild['epoch'], $new_pkgbuild['pkgver'], $new_pkgbuild['pkgrel']); } else { @@ -389,8 +417,10 @@ if ($uid): } # Update package depends - if (!empty($new_pkgbuild['depends'])) { + if (empty($depends) && !empty($new_pkgbuild['depends'])) { $depends = explode(" ", $new_pkgbuild['depends']); + } + if (!empty($depends)) { foreach ($depends as $dep) { $deppkgname = preg_replace("/(<|<=|=|>=|>).*/", "", $dep); $depcondition = str_replace($deppkgname, "", $dep); -- 1.8.2.rc2.352.g908df73
On Tue, Mar 05, 2013 at 01:37:58PM +0100, Lukas Fleischer wrote:
This allows for adding a metadata file called ".SRCINFO" to source tarballs to overwrite specific PKGBUILD fields. .SRCINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
This format closely matches the .PKGINFO format that is used for binary packages in pacman/libalpm. It can be extended by field name prefixes or sections to support split packages later.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> ---
Note that I failed to "--annotate" and add "[RFC]" to the subject line. Comments and opinions welcome.
web/html/pkgsubmit.php | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-)
[...]
On Mar 5, 2013, at 1:37 PM, Lukas Fleischer wrote:
+ if ($line[0] = '#') { + continue; + }
Do you mean if ($line[0] == '#') { ? Alex
On Tue, Mar 05, 2013 at 02:23:38PM +0100, Alexander Griesbaum wrote:
On Mar 5, 2013, at 1:37 PM, Lukas Fleischer wrote:
+ if ($line[0] = '#') { + continue; + }
Do you mean if ($line[0] == '#') {
Yes, I changed this to if (empty($line) || $line[0] == '#') { during testing but forgot to amend the commit. `git commit -a --amend`'ed locally. Thanks!
?
Alex
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. Alex [1] https://projects.archlinux.org/aur.git/tree/web/html/pkgsubmit.php
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...
Alex
[1] https://projects.archlinux.org/aur.git/tree/web/html/pkgsubmit.php
On Tue, Mar 5, 2013 at 4:02 PM, Lukas Fleischer <archlinux@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? Alex
On Sat, Mar 16, 2013 at 5:38 PM, Alexander Griesbaum <agrsbm@gmail.com> wrote:
On Tue, Mar 5, 2013 at 4:02 PM, Lukas Fleischer <archlinux@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
On Sun, Mar 17, 2013 at 4:05 PM, Dan McGee <dpmcgee@gmail.com> wrote: <snip>
Tolerant of what besides badly formed input data? This is machine generated info that happens to be human readable. <snip>
You're absolutely right, I just ignored that fact. Thanks for pointing me to this and sorry for the noise. Alex
participants (3)
-
Alexander Griesbaum
-
Dan McGee
-
Lukas Fleischer