Re: PKGBUILD parser

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux