Seriously... WTF is this:
source=("WorldOfGooSetup.1.41.tar.gz"::"file://WorldOfGooSetup.1.41.tar.gz")
source=("file://linux-anomaly-i386-1327984913.tar.gz")

why not just
source=("WorldOfGooSetup.1.41.tar.gz")

I see absolutely no benefit of the file:// part here. And if the file is not in the directory with the PKGBUILD, just symlink it.

I am fairly sure we have rejected this as useless before...

+1. Seems like the wrong solution to a non-problem.

1) Not using protocol makes it impossible for user to set customized file location prompt, described in linked topic. Using symlink to achieve trivial goal is rather inconvenient IMHO.
2) Using file name does not allow distinguishing simply missing files from files, which should be supplied by user. This makes sense both for users and AUR engine. On other hand, "file:" links are properly highlighted in AUR and quite intuitive (as file:// URLs conventionally refer to local files).

1) how is editing a generic PKGBUILD to point at the location for your system any more inconvenient than adding a symlink?

>> 1) how is editing a generic PKGBUILD to point at the location for your system any more inconvenient than adding a symlink?

? Sorry, I probably misunderstood you somewhere. Have you read https://bbs.archlinux.org/viewtopic.php?id=151690? Nice-looking zenity file selection dialog is more convenient than anything else IMHO.

Also using "file:" URLs is better alternative to interactive downloading routines, used by rest of Humble Indie Bundle packages (and lots of other commercial packagers in AUR).

PKGBUILDs are not, nor should they ever be, interactive. There's nothing "nice" about Zenity, especially on a headless server or any other machine not running X for a given session. If a file is missing, your "prompt" is an error from makepkg. Go edit the PKGBUILD.

I still have no idea what problem this solves. It really sounds to me like you want to use SRCDEST. If that isn't enough, I don't know what to tell you.

Also, couldn't you just put this in for yourself? I don't see why this has to be a change to the default makepkg.conf file. If people want the zenity interface (I personally do not need or want it), then they can add it themselves. Heck, couldn't it even be added into your individual pkgbuilds, if you don't need it globally?

>> If people want the zenity interface..

>> PKGBUILDs are not, nor should they ever be, interactive. There's nothing "nice" about Zenity, especially on a headless server or any other machine not running X for a given session. If a file is missing, your "prompt" is an error from makepkg. Go edit the PKGBUILD.

Sorry for my terrible English, I, obviously, agree with you - PKGBUILDs should not be interactive. As I already stated, "file:" URLs can act as _alternative_ to _interactive_ routines, used in many AUR packages.

>> I still have no idea what problem this solves

Appending the single string to default PKGBUILD allows users to download existing PKGBUILDs, containing "file:" URLs, and use them without getting "no handler for protocol found" error or manually adding handler to makepkg.conf. Note, that proposed DLAGENT, which is 'file::/bin/cp %u %o' is not interactive and does not contain any calls to zenity, which may pose treat to headless servers etc. Solution, described in mentioned forum topic, may be added to makepkg.conf by user himself, after considering fact, that all his PKGBUILDs come from AUR and are usually launched in some interactive environment with zenity installed.

Using "file:" URLs has following benefits, which have nothing to do with SRCDEST variable:

1) AUR can potentially be modified to use "file:" URLs to distinguish packages with purposefully missing files from packages with erroneously not added files.
2) "file:" URLs work as hints for users about the same thing.
3) Users can define custom handlers for "file:" URLs in makepkg.conf.

> 1) AUR can potentially be modified to use "file:" URLs to distinguish packages with purposefully missing files from packages with erroneously not added files.

This just makes no sense. If the file is intentionally not added to the AUR tarball, then it is an external package. In my opinion, this is normal.

> 2) "file:" URLs work as hints for users about the same thing.

Not needed for normal makepkg usage.

> 3) Users can define custom handlers for "file:" URLs in makepkg.conf.

They can do this anyway. I don't see the problem. If they want it, then they can get it.

This whole thing, like Allan said, seems like something that we don't need to care about. I will never use it, and see no reason why this should be added when a simple `ln TARGET LINK_NAME` is needed.

>> 1) AUR can potentially be modified to use "file:" URLs to distinguish packages with purposefully missing files from packages with erroneously not added files.

>This just makes no sense. If the file is intentionally not added to the AUR tarball, then it is an external package. In my opinion, this is normal.

How do you find out, that it is missing on purpose, rather then by mistake? I am not talking about HUGE NOTICE on package page, but rather about automatic handling of tarball uploads.

>> 2) "file:" URLs work as hints for users about the same thing.

> Not needed for normal makepkg usage.

There are no official packages using SCP to fetch sources. Do you imply, that "scp:" handler, present for some reason in default makepkg.conf, is also not needed for normal makepkg usage? What's wrong with "file:" handler then?

>> 3) Users can define custom handlers for "file:" URLs in makepkg.conf.

>They can do this anyway. I don't see the problem. If they want it, then they can get it.

They can already, but only after being instructed to do so.

source=("WorldOfGooSetup.1.41.tar.gz") # needs manually download from ...

> How do you find out, that it is missing on purpose, rather then by mistake? I am not talking about HUGE NOTICE on package page, but rather about automatic handling of tarball uploads.
makepkg will warn you if the file is missing and it cannot be retrieved from an external source. Do you need more warnings?

>There are no official packages using SCP to fetch sources. Do you imply, that "scp:" handler, present for some reason in default makepkg.conf, is also not needed for normal makepkg usage? What's wrong with "file:" handler then?
No, but that is an external protocol. That is what the DLAGENTS are for (emphasis on 'The download utilities' [from /etc/makepkg.conf])

>They can already, but only after being instructed to do so.
So Arch is a do it yourself distro. Do you want us to wipe, too?

>> source=("WorldOfGooSetup.1.41.tar.gz") # needs manually download from ...

Sounds nice, except that it does not solve problem of "file:" URLs.. no, forget about "file:" URLs - why force users to bloat their PKGBUILDs and package descriptions, when issue can be solved by introducing and documenting unified protocol? Seriously, your proposal is more then 30 bytes long, when original protocol handler line is just 21 bytes long :/

There still doesn't seem to be a compelling reason to do so. Even if they don't do what Allan said, makepkg will still tell you that it can't find the source. Files are already searched for, why even bother duplicating that? ln exists, cp exists, mv exists. There are tools that you can use to make it work that require no extra bytes.

Also, might I add, both of the pkgbuilds ALREADY SAY "(requires copy of the full game)".

> Even if they don't do what Allan said, makepkg will still tell you that it can't find the source.

Yes, it will, unless PKGBUILD author implements more robust handling of this case. Just like adding support for SCM protocols to makepkg this change won't magically improve existing PKGBUILDs, instead it can become foundation for further enhancements.

> both of the pkgbuilds ALREADY SAY "(requires copy of the full game)".

This is entirely different issue, which is illustrated by game packages having comments about missing files despite this notice being in descriptions of most from the beginning.

Devs, correct me if I'm wrong, but having the file: protocol still just seems ridiculous to me.

makepkg already checks for the files being there or not being there. Adding in something that is already there just seems extremely pointless to me. Yes, you may have to download and move/link a file, but even with the file: protocol, you're essentially doing the same thing. How it would improve any pkgbuilds in the future is beyond me. Comparing this to adding SCM support is outlandish, to say the least. Some pkgbuilds are already made to work with the new git integration of pacman (I know that I have helped port over a few for i3*-git) and it takes out a lot of duplicate code. Once again, the file: protocol is already supported by not putting a url in the source array.

There are warnings in place when a source is not found, makepkg already handles local files (in or linked to the correct place), and not everyone has the need or want for a graphical interface to select packages.

Main reason, why people use "file:" protocol in their PKGBUILDs, is AUR visually highlighting such links in web interface. This feature request is based on real demand (I know about at least 4 other users only among Humble Indie Bundle AUR package maintainers, who use this protocol in their PKGBUILDs), which means that number of people already consider this feature logical and convenient. The rest won't be affected at worst. I believe, that assisting users event to small degree is the main reason for existence of default configuration files. Devs, please, correct me if I'm wrong.

Ok, you're wrong. There's several problems here which I'm happy to delineate/reiterate:

1) Defaults exist because they cover the *popular* use cases, not the *edge* cases. Want to bring up scp again? I'll point out that it's been there since before you started using Arch. git blame shows that it's likely to be 5+ years old. Whether or not it's widely used at this point is totally irrelevant. You need *real* reasons why file:// should be a default.
2) This proposal applies to an absurdly small number of *bad* packages. Source tarballs are meant to be *complete* recipes. When you start intentionally unincluding files (regardless of the reason), you're straying from the norm. Period. There's zero reason for us to support bad use cases.
3) Your proposed DLAGENT is faulty because it *requires* that the source and destination be different. Ever try copying a file to itself? It fails. This is completely unexpected behavior from a DLAGENT because we assume that local files... are already local.
4) You're ignoring the obvious solution -- for the SMALL number of packages that you feel "require" this hack, just add the DLAGENT to the PKGBUILD yourself. It's self documenting and you get your silly hrefs in the AUR (assuming the AUR will actually highlight these).
5) My take on the AUR is that the interface itself is supported, but the contents are not. Making almost any argument based on the contents of AUR packages isn't likely to win you any ground (as you're seeing here).

>> Defaults exist because they cover the *popular* use cases, not the *edge* cases.

Unfortunately, there is no way for something to become widespread without at least some initial adoption. AFAIK most users do not even have an idea about DLAGENTS being of any use.

>> You need *real* reasons why file:// should be a default.

Aren't you attaching too much importance to this? In my opinion, if this case does not have any impact on most users, there is no need for such high requirements.

>> Your proposed DLAGENT is faulty because it *requires* that the source and destination be different.

Could you please elaborate on this one? This behavior seems legitimate for me.