[aur-general] Trusted User Application

[Ray Rashif]

Again, that is where the simplicity/Arch principle comes in. Things happen
when and where approriate; making sense of it all. There are 2 primary
cases:

1) Traditional reason for variables - shorter alternatives to longer strings

2) Portability/flexibility - other programmers are able to manipulate your
code easily (for PKGBUILDS; those editing it)

So if the script doesn't have any content relating to (1) or (2) then yet
another variable is indeed pointless. We should avoid them unless the
benefit is practically significant.

Say, for instance, a short PKGBUILD where the source archive's $pkgver !=
real $pkgver. You are going to submit it to [unsupported] where the AUR web
interface cannot resolve custom variables, and the source archive's name has
an underscore. You create _pkgver as the new one, and you use it in the
source array as ${pkgname}_${_pkgver}, which could do with some cosmetic
surgery. Then it'd be up to you to decide whether this new variable, or
having a clean look on the web interface, is more beneficial/"important".

Since bumping pkgver will not change the source, introducing _pkgver makes
it easy to update. At the same time, though, if one is editing the PKGBUILD
the source array isn't that many lines down and thus, is as easy as changing
the value of a variable. It's a matter of weighing priorities; takes a few
seconds before clicking on "submit". In [community] (ABS), this isn't a
problem but then - as a TU - you should be able to do the weighing just
fine. I don't know if I'm guilty as an [unsupported] user but I sure hope
not =P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/aur-general/attachments/20080604/76e9e940/attachment.htm>