Why not just list them one after the other? Is there any special reason why you would need just the good ol' way of using the variables?
It is way easier to understand, and I don't thking a few copy-paste should be a problem when you make a PKGBUILD...

Yes we can put one after the other but for me it's better to use variables in some case.
see firefox-i18n PKGBUILD for exemple.

Okay, I'm not in the development team at all, so all I say is more personal opinion and preference. Also it comes from what I gathered recently while fixing some other issues how AUR parsed the PKGBUILD files.

So: the "eval source=..." relies on how the PKGBUILD parsing is implemented in makepkg - basically your PKGBUILD is a bash script in itself, and makepkg just loads all the variables and the build() function to execute. E.g. the extra/firefox-i18n can only work because this is the current mechanism.

There is a discussion going on that for more security and flexibility the PKGBUILD parsing will be rewritten in a way that wouldn't rely on this bash "trick". Then, for example that package will stop to work - since it does not conform to the Arch Packaging Standards as it is a requirement on AUR (just check the front page).

In my opinion it is unfortunate that this package, in the extra repo, does not conform to the standards. And the reason is I think laziness, since how much efficient you want to be when your script is already just a few lines? Efficient in what respect? Space? Amount of work it needs to be done? If you can do it with eval, than it is not more than a few lines of copy-paste. How many times you write a PKGBUILD like that that it would _seriously_ save any time? If you do it to be easier to check whether whether things are alright - you should check it anyway.

As I said, that's just my feeling.

> There is a discussion going on that for more security and flexibility the PKGBUILD parsing will be rewritten in a way that wouldn't rely on this bash "trick".

err, what, where?

> Then, for example that package will stop to work - since it does not conform to the Arch Packaging Standards as it is a requirement on AUR (just check the front page).

Can you point me directly to the section of the Arch Packaging Standards that explicitly prevents this usage?

What is preventing them being uploaded? It seems the AUR can actually handle them correctly: http://aur.archlinux.org/packages.php?ID=16296

I personally have no idea, why AUR could handle that sunbird package...
Last time I couldn't see any code in the aur web/html/pkgsubmit.php that would make it possible (checked on http://projects.archlinux.org/?p=aur.git;a=summary )... It is properly maintained, CVS type package, so might be an exception then a rule...

There's a difference between explicitly preventing or explicitly allowing something.

I personally would go in these kind of things the conservative way: whatever is allowed, do that. If you want to do the things that are not explicitly prevented, but not listed either (maybe because people the time of writing weren't thinking of that particular "trick") then be prepared that it won't always work. Any PKGBUILD parser (like the one on AUR) can only follow what is listed in a documentation. If you want something else just go ahead, implement it, send in the patch. That's how everybody else is doing it too, I think.

I wouldn't really want to support this type of usage.

Sure, there may be situations where such scripting makes sense, but that seems
to be delegated to separate scripts and not dumped in the PKGBUILD itself.
See the build scripts for vi for an example.

The patch for this is in git anyhow.