[aur-general] Promoting use of .AURINFO

[Jerome Leclanche]

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 properly
>> displayed by AUR (or maybe I've missed something). But why do you want to
>> 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 I
>>    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