Dan McGee wrote:
I don't like the @@ and :: syntax. Maybe "git://remotename//http://projects.archlinux.org/git/pacman.git"? That way we can simply look for "git://" and also easily figure out if there is a remote name or not. "//" should also be a safe delimiter because in the URL it would be collapsed to "/" anyway. Heck no, minus -1000. We are **not** reinventing a URL syntax. This is confusing, misleading, and awful. Look at this: git://remotename//git://projects.archlinux.org/pacman.git
I don't even know what remotename is (but if that can contain a '/', my eyes will really bleed). The double URL specifier (using the same protocol twice!!) is likely not allowable or recommended by http://tools.ietf.org/html/rfc3986.
If you are trying to stick with URI/URL format, I'd much rather see git+http:// in this case, which is a lot like the 'svn+ssh://' protocol you can use, etc. And then use fragment identifiers perhaps (RFC 3986, 3.5, '#branchname') to identify the branch name.
Please do this, and modularize the handlers in such a way that users can create new ones without hacking/patching the makepkg source. For example, create a directory similar to /etc/profile.d with files that get sourced by makepkg. Files in this directory could contain functions with scheme prefixes and common names, e.g. for git+http you might have git_http_download and for svn+ssh you would then have svn_ssh_download. The *_download function would be responsible for handling cloning and updating as necessary. It could accept the URL minus the fragments as first argument, the target/build directory as second argument, and then the fragments as additional arguments. Obviously that's just an example off the top of my head and you will have better ideas of how to implement it (e.g. maybe leave parsing to the function). The real purpose it to effectively create a VCS plugin system. Aside from providing users with flexibility, it would also crowdsource the creation of new VCS handlers. They could even be provided as optdepends. For versions, the *_download function could return one or there could be a special *_version function, but mixed sources may be a problem in that case. You could simply make it a guideline/requirement that the version be the date of the last VCS release or source modification. The version of the package would then be the version of the last release/modification of any source. That should simplify version handling across different VCS. I don't recommend using release tags as versions because there will be no way to compare them meaningfully in many (most?) cases. Just some thoughts. Regards, Xyne