[pacman-dev] code reuse for PKGBUILD

[LANGLOIS Olivier PIS -EXT]

Kent,

I'm a new Arch-user having interest eventually to contribute if I can, so please take with a grain of salt my opinion. I do not know enough the pacman-dev community to predict how your suggestions will be perceived. I see some merits in them but here are important benefits of the "no code reuse" policy.

1. Avoiding dependency issues in a system that manage dependencies is a good thing. With your suggestion, you would eventually end up with PKGBUILD not immediately usable because you need to update your reusable perl module


2. "no code reuse" also implicitly enforce KISS

While I love Perl for some tasks such as processing nm output to create automatically bps in gdb, I feel that some languages weren't meant for reusability, with all respect for Perl, I believe that it is one them.

My past experience for having work a year in a Perl shop is that, give just a couple of months to a reusable Perl module and it will at some point use OO Perl with Moose that needs a special module to highjack the import statement so that lookups in a serie of yaml files are performed to build dynamically the module search path env for the hundreds of required Perl module and the beast will grow to several hundred of MBs during runtime and will become slow like a camel with a moose head. It will become so complex that no mere mortals will understand what is going on, when the thing breaks.

I started to play with PKGBUILD files and I just like them as they are.

That is just my opinion.

Greetings,
Olivier
>
> If you want to see something
>
> A. Scary
> B. Along the lines of what I'm asking
> C. To see how most of this is pretty easy to implement with just plain old
> bash
>
> https://gist.github.com/4227633#file_pkgbuild
>
> ^
>
> Works.
> - makepkg -S  # works as expected
> - makepkg      # works as expected
>
> All I'm basically asking for is "hey, maybe that perlmod.sh file should be
> shared, and put in a place where only people we trust are editing it"
>
> After all, that would *increase* security, and decrease the need for every
> PKGBUILD to be so heavily reviewed for exploits.
>


________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.