On 10/05/10 02:06, Loui Chang wrote:
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
On Sun, May 9, 2010 at 2:44 PM, Allan McRae<al...@archlinux.org>  wrote:
Sourcing is dangerous if the PKGBUILD is from an untrusted source.  It also
fails with package splitting...

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.

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.

The joy of PKGBUILDs is that they are so flexible. The problem with PKGBUILDs is that they are so flexible.

Allan

Reply via email to