[aur-general] 'provides' info in AUR

[Jerome Leclanche]

On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner <d at falconindy.com> wrote:
> On Wed, Dec 11, 2013 at 06:12:59PM +0000, Jerome Leclanche wrote:
>> On Wed, Dec 11, 2013 at 5:52 PM, Sam S. <smls75 at gmail.com> wrote:
>> > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche <adys.wh at gmail.com> wrote:
>> >
>> >> I don't understand why makepkg -S
>> >> doesn't include the .PKGINFO file from makepkg (and subsequently the
>> >> AUR would use that if present instead of the grep system which fails
>> >> as soon as variables/expansions are involved which is every other
>> >> package). All the implementation is there.
>> >>
>> >
>> > It would probably be better then what we have now, but a perfect solution
>> > would also account for PKGBUILDs that use Bash conditionals to set
>> > different variables on i386 systems than on x86_64 systems (which is pretty
>> > common among AUR packages that package upstream binaries rather than
>> > compiling from source).
>> >
>> > Reading values from .PKGINFO would populate the AUR with the values for
>> > whichever architecture the package uploader happened to use. (So if the
>> > maintainer changes, or the same maintainer works on different computers, a
>> > simple re-upload of an AUR package could suddenly change the package's
>> > meta-info, i.e. the AUR would become more "fragile".)
>> >
>> > Of course, the "perfect solution" would be pretty difficult to implement.
>> > Gentoo had a GSoC project last year [1], to implement an efficient and safe
>> > (side-effect free) limited Bash parser / pseudo-interpreter in C++,
>> > sufficient to extract all necessary values from Genoo's equivalent of
>> > PKGBUILDs. Surely, this could have been useful for the AUR as well. But I
>> > can find no evidence of continued project activity after the GSoC period
>> > ended, so it appears they have given up... :(
>> >
>> > ---
>> > [1] http://dev.gentoo.org/~qiaomuf/libbash.html
>>
>> I love the fact someone could be working on a bash parser but that
>> solution is *insane*.
>
> It's designed to be incomplete, and the project appears very dead.
>
>> This is a solved problem: use a metafile compiled by whatever tools
>> you use in your distro/domain that can be parsed safely and easily.
>> For Arch, those are PKGINFOs.
>
> No, go see historical conversations about a mythical .SRCINFO -- this is
> what .AURINFO is based on. .SRCINFO is vaporware right now, and I again
> refer you to unresolved discussions about how it would handle split
> packages and package-specific overrides.
>
>> Good point on the differences per arch. I guess the obvious solution
>> that comes to mind here is to have makepkg -S generate the source
>> files for each arch value (eg. PKGINFO.x86_64, etc) but that's not
>> necessarily good and is the subject of another discussion imo.
>
> To be clear, .PKGINFO is not the solution here. This file describes a
> built package (something the AUR explicitly does not support).
>
> d

Care to explain the reasoning? I'm looking at a few example PKGINFOs
and they contain nothing that can exclusively be generated at
package() or build() time (other than pkgver but that's already the
case currently).

J. Leclanche