[aur-general] 'provides' info in AUR

Jerome Leclanche adys.wh at gmail.com
Wed Dec 11 15:21:44 EST 2013

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

More information about the aur-general mailing list