On Wed, Dec 11, 2013 at 06:12:59PM +0000, Jerome Leclanche wrote: > On Wed, Dec 11, 2013 at 5:52 PM, Sam S. <sml...@gmail.com> wrote: > > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche <adys...@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
