[aur-general] 'provides' info in AUR

[Xyne]

On 2013-12-11 22:57 +0000
Jerome Leclanche wrote:

>These are all issues that can easily be fixed. Sources/checksums can
>be added, extra architectures can be generated, and split packages can
>be described in sections. (.conf aka .ini file format would be a
>perfect fit here and would be forwards-compatible with the current
>format but pretty much anything with sections would do.)
>
>Just to be clear, I'm not advocating to specifically use .PKGINFO;
>just to use a compiled, parseable file (such as the .SRCINFO that was
>talked about).. and it seems the consensus is that this is the best
>solution. Am I wrong? What are the issues with .SRCINFO?

My response is not directly at you in particular. I'm reply to the thread as a
whole.

The real problem is that we are attacking this from the wrong end. We should
no be trying to excavate machine-parsable metadata from Bash. We should be
thinking of ways to encapsulate the metadata in a flexible way that can be used
to generate Bash.

This would solve all of these problems and open the doors for numerous
packaging tools (graph generators, metadata miners, fully automated repo
generators, etc.).

I've played around a bit with encoding package metadata in JSON. All of the
packages on my site are autogenerated from JSON files with associated Bash
stubs containing functions. My own approach is customized to my release scripts
and not immediately generalizable, but the idea itself is workable.

The key selling point of Bash is flexibility due to it being a full scripting
language, but for the metadata itself we don't need the full flexibility. I
think the following would suffice:

1) A convention for expressing per-package namespace for split packages, with a
   way to inherit and override from other namespaces to avoid redundancies.
   This can be done with sub-objects and a little syntax, e.g.
   {
     "python-foo" : {
        ...
     }, 
     "python2-foo < python-foo" : {
       "depends" : ["python2", ...]",
       ...
     }

2) Variables for convenience. A top-level field to specify a delimiter would
   suffice, e.g. {"variable delimiter" : "$", ...} and then later {..., "url" :
   "http://example.com/$pkgname$-$version$.tar.gz", ...}. The file could be
   safely interpolated. Interpolation requires some thought but it should be
   easy to do in all sane cases.

3) The build, package, prepare and version functions would obviously still be
   written in Bash, but they would be kept in a separate file and devoid of
   metadata.

4) If truly necessary, syntax for inserting command output could be added as
   well, again with a top-level limiter for the command. This would allow
   parsers to decide exactly which commands to run, if any. The use of such
   commands would be restricted to cases in which they are absolutely necessary
   (if there are any).

Overall, it is not much more verbose than current PKGBUILDS:

    "powerpill": {
      "pkgdesc": "Pacman wrapper for parallel and segmented downloads.",
      "pkgrel": 1,
      "pkgver": "2013.5.13",
      "arch": "any",
      "backup": [
        "etc/powerpill/powerpill.json"
      ],
      "depends": [
        "python3",
        "pyalpm",
        "pm2ml>2012.12.12",
        "reflector",
        "aria2"
      ],
      "optdepends": {
        "python3-threaded_servers": "internal Pacserve support",
        "rsync": "Rsync download support"
      },
      "md5sums": [
        "0f0d4c0096bd60287ab923038c3bbc47",
        "f58432feaaeb339e5d6b3692d3cecf17"
      ],
      ...


As soon as I have some time I will provide a proof-of-principle implementation
and post a RFC.

Regards,
Xyne