[aur-general] 'provides' info in AUR

Dave Reisner d at falconindy.com
Wed Dec 11 16:11:26 EST 2013


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.



More information about the aur-general mailing list