On Mon, May 10, 2010 at 1:23 AM, Allan McRae <allan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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.
