[pacman-dev] The great VCS packages overhaul of 2015

[Xyne]

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