On Mon, May 10, 2010 at 1:23 AM, Allan McRae <allan@archlinux.org> wrote:
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<allan@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.
The biggest problem indeed comes from any variables that are declared inside a function. Well, it's easy, let's just make a rule to forbid it. Any AUR packager who breaks the rule will have its package data messed up in the AUR interface. Too bad for him/her. The klibc package is/was an exception, not the rule, and it wasn't on AUR so less problematic (still problematic for other tools like my python check-packages for integrity check, but well). So the main thing is split variables that need to be moved top-level. Dan, Aaron and I had some proposals / examples how to deal with that. You were included in the few mail exchanges we had but I am not sure if you did receive all of them as you didn't reply directly in that thread, I will forward it to you.