On Mon 10 May 2010 09:23 +1000, Allan McRae wrote: > On 10/05/10 02:06, Loui Chang wrote: > >On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote: > >>But I just had an idea now, if we're thinking about AUR use case : > >>makepkg --source could generate a suitable and parsable file providing > >>all information that AUR needs, and ships that next to the PKGBUILD in > >>the source tarball. Does that sound crazy ? > >>This would not fix the problem now, but it could fix it eventually, > >>when most pkgbuilds are re-submitted. Or this parsable file could be > >>generated for all pkgbuilds in a row, just for the conversion, in a > >>chroot/jail on a machine not in production. > > > >Yeah I've thought about this as well. Source packages could have a > >similar format as binary packages with a .PKGINFO file to present the > >metadata in an easily parsable format. > > > >You can read some of my incomplete brainstormings here: > >http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz > > I am told I like to be really negative anytime this is bought up... > it is not deliberate, I just see the barriers to this working. So > here we go! I know you have pointed out some problems already and > this is related. No problem. I didn't really share this before because I hadn't even thought of a real solution. Since it was mentioned though, I thought I'd share my thoughts. There are definitely many barriers to sort out. > makepkg does not actually parse any of the splitpkg overrides until > build time. How do we get the packaging variable overrides without > actually making the package (and on every architecture)? We would > need to extract the needed fields from the package functions somehow. > So that brings us back to needing to hack a bash parser in makepkg or > to actually require the package building to take place before you can > create a source package. And this is not restricted to package > splitting... > > e.g. > > pkgname=foo > ... > # depends not needed at make time > # depends=('bar') > ... > package() { > depends=('bar') > } > > Welcome to the world of makepkg hacks... And do not think such > hacks are not used. The old klibc PKGBUILD generated a provides > array in the build function on the basis of a file name only > available at the end of the build process. Yeah there'd have to be some kind of standard constructs for all these kinds of hacks like platform specific dependencies, etc. That would probably mean changing or expanding the PKGBUILD spec. I wouldn't be afraid to do that, but it might not sit well with compatibility or with Arch principles. > The joy of PKGBUILDs is that they are so flexible. The problem with > PKGBUILDs is that they are so flexible. Indeed.
