On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner <[email protected]> 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. <[email protected]> wrote: >> > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche <[email protected]> >> > 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
