On Thu, Dec 12, 2013 at 7:11 AM, Dave Reisner <d@falconindy.com> wrote:
On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner <d@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@gmail.com> wrote:
On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche < adys.wh@gmail.com> wrote:
I don't understand why makepkg -S doesn't include the .PKGINFO file from makepkg (and subsequently
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
maintainer changes, or the same maintainer works on different computers, a simple re-upload of an AUR package could suddenly change the
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
On Wed, Dec 11, 2013 at 08:21:44PM +0000, Jerome Leclanche wrote: the the package's period
ended, so it appears they have given up... :(
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.
What is to stop us using both? I don't think anyone has said we should stop parsing the PKGBUILD for the AUR and exclusively parse a .PKGINFO instead. It would just provide some supplementary information that isn't currently available in an easy to parse method from the PKGBUILD without running arbitrary code on the server side. Reading both files would solve that, right? Regards, Justin Dray E: justin@dray.be M: 0433348284