[aur-general] 'provides' info in AUR

Dave Reisner d at falconindy.com
Wed Dec 11 13:42:20 EST 2013

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).


More information about the aur-general mailing list