[aur-general] 'provides' info in AUR

[Hugo Osvaldo Barrera]

On 2013-12-12 01:39, Xyne wrote:
> 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

I'm very much in favour of this (I'd even though of something slightly
similar at some point). We need a PKGBUILD2.0 format that can overcome
of our current limitations.

The downside is flexibility. What if the sources are complete different
for each architecture. At the moment, we can have an "if" in place. The
same applies for depends that vary according to architecture. Would we
just have a bunch of differently named-fields?

Before you post an RFC, a complete example of a really complex package
(with wierd sources, depends and stuff) would be great! :D

Anyway, if this becomes a reality, feel free to CC me; I'd be willing
to help the development of tools for this format! :D

-- 
Hugo Osvaldo Barrera
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20131212/d88572f1/attachment.asc>