[aur-general] 'provides' info in AUR

[Justin Dray]

On Thu, Dec 12, 2013 at 7:11 AM, 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.
>
>
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 at dray.be
M: 0433348284