[aur-general] Promoting use of .AURINFO
justin at dray.be
Sun Jan 12 17:49:39 EST 2014
On Mon, Jan 13, 2014 at 6:17 AM, Jerome Leclanche <adys.wh at gmail.com> wrote:
> On Sun, Jan 12, 2014 at 3:11 PM, Lukas Fleischer
> <archlinux at cryptocrack.de> wrote:
> > On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote:
> >> Hello,
> >> I was under the impression that .AURINFO was introduced to override some
> >> fields in PKGBUILD when they are written in format which can't be
> >> displayed by AUR (or maybe I've missed something). But why do you want
> >> force it's usage for all packages? In most cases AURINFO will just
> >> duplicate same fields from PKGBUILD.
> > The long-term plan is to use it for all AUR packages, improve the format
> > and finally make it an official feature of makepkg(8) (the file will
> > probably be called .SRCINFO then but we're far from there). See my other
> > reply to Sebastien for some reasons on why it should be used.
> So the official goal is to have it generated as part of makepkg -S?
> Because I see that as the only way the format will get popular: if
> it's nobody's problem.
> J. Leclanche
> >> Also I have some questions about it's format:
> >> 1) If package has different dependencies for 86_64 and 686, what should
> >> put in depend array?
> > Good question. This cannot be answered properly, though, since
> > dependencies actually are a property of the binary package and not a
> > property of the source package. Maybe we should loosen the format for
> > dependencies of source packages and allow optdep-like comments?
> > Something like:
> > depends = foo
> > depends = bar
> > depends = foobar: x86_64 only
> > Just an idea. Comments welcome.
> >> 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I
> >> upload package with name 'foo' and overriden name 'bar' will someone
> >> be able to upload new package with name 'foo'? Or 'bar'?
> > Only the information from .AURINFO will be used. You can already trick
> > the AUR into reading a completely different name from the PKGBUILD than
> > it actually produces (and that problem is unavoidable), so that isn't a
> > (new) issue.
> >> --
> >> Regards,
> >> Anton Larionov
It might also be a good idea to write out what fields are available and
their purpose on the wiki similar to the PKGBUILD page (
https://wiki.archlinux.org/index.php/PKGBUILD) and perhaps link to it from
the AUR user guidelines page? It will be forgotten by most packagers if the
only information about it is a commit message and a mailing list thread.
E: justin at dray.be
More information about the aur-general