On Wed, Dec 11, 2013 at 9:11 PM, Dave Reisner <[email protected]> wrote: > On Wed, Dec 11, 2013 at 08:21:44PM +0000, Jerome Leclanche wrote: >> 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 > > Here's a few reasons that come to mind: > > 1) As you've already discovered, you'd need a .PKGINFO file for every > potential architecture, rather than just a .SRCINFO which might describe > what architectures are known available. A .SRCINFO could express all > package and architecture specific overrides. The fact that an override > exists might be a useful bit of information to convey. > > 2) .PKGINFO doesn't contain things that are useful for source packages, > like, say... the source URL? checksums? > > 3) You can't possibly express split packages well. Having pkgname fields > in a .SRCINFO would mean you could describe all packages created by a > PKGBUILD rather than having some loose association between a PKGBUILD > and some possible .PKGINFO files which it might have generated. > > This is about *source* packages. The metadata needs for source packages > are not the same as the needs for binary packages. >
These are all issues that can easily be fixed. Sources/checksums can be added, extra architectures can be generated, and split packages can be described in sections. (.conf aka .ini file format would be a perfect fit here and would be forwards-compatible with the current format but pretty much anything with sections would do.) Just to be clear, I'm not advocating to specifically use .PKGINFO; just to use a compiled, parseable file (such as the .SRCINFO that was talked about).. and it seems the consensus is that this is the best solution. Am I wrong? What are the issues with .SRCINFO? J. Leclanche
