[aur-general] 'provides' info in AUR

[Jerome Leclanche]

On Wed, Dec 11, 2013 at 9:11 PM, Dave Reisner <d at falconindy.com> 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 <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
>
> 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