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

[Allan McRae]

It is well know that the VCS package support in makepkg is subpar...
The number of bugs about this is into double figures.  There have also
been some patches submitted attempting to be able to use the source=()
array in PKGBUILDs to specify a VCS repo and remove a lot of the
repetitive crap involved for repo checkout/updating in the current
PKGBUILDs.

To get the ball rolling again, I think we should pick one VCS system and
flesh out what we need and what the prototype PKGBUILD would look like.
 Then we can move on to the other VCS systems and finally implement it.
 I guess by the time all the bikeshedding is finished, this will all be
done by 2015 and hence the subject line.  :)


I am going to start with git.

Current:
pkgver = the date the package was built
_gitroot = the url of the git repo
_gitname = the name of the directory we check out the repo into...

According to the man page, _gitname is supposed to be a branch or tag
but that is all lies.


What would we like to have for a flexible git package implementation?
 - url of the repo
 - be able to specify the branch/tag/commit to use (and appropriate
combinations)
 - a decent pkgver


1) URL:
There were previous patches to the mailing list that never really got
finished, but I think we were fairly happy with this syntax:

source=(git://projects.archlinux.org/pacman.git)
source=(git@@http://projects.archlinux.org/git/pacman.git)

Does it make any sense to allow the "::" syntax here?  i.e.
source=(git@@dirname::http://projects.archlinux.org/git/pacman.git)

where dirname is the name of the directory it checked out into?   I am
thinking we should probably do the checkout into $vcsdir=$startdir/vcs,
so this would only be needed if
#1 - we supported multiple VCS checkouts in one PKGBUILD there were two
that wanted to used the same name...
#2 - another source file conflicted

#2 is readily dealt with and I am not sure we should allow #1 (see
below) so I would vote to skip it until a genuine need is shown.


2) Specifying commit to work with:
I think that this is the difficult bit...   the syntax with the source
array is already convoluted enough, so I do not think they should be
added there.  So that suggests we go with assigning them to variables
like _git_branch, _git_commit, _git_tag... etc.

But what if we have two git sources? For example, say pacman allowed
building against an internal copy of libarchive if a folder named
libarchive was found in its root directory. So:

source=(git://projects.archlinux.org/pacman.git
        git://github.com/libarchive/libarchive)

build()
{
  cd $srcdir/pacman
  ln -s ../libarchive
  ./autogen.sh
...

It might seem a somewhat convoluted example, but (e.g.) gcc does allow
in source tree building of many of its dependencies.  The question is
should we consider this outside the realms of the reasonable and state
one VCS repo should be one package.   I'd say 99.999% of VCS PKGBUILDs
(at a lower bound) would never use two VCS sources... and the ones that
do need this could do manual checking out of the non-main source within
the PKGBUILD anyway.


3) pkgver
Use output of "git describe" (with a s/-/_/) and fall back to "git
rev-list HEAD | wc -l" (with a trailing commit id added) if there are no
tags in the repo.


PROTOTYPE:

pkgname=pacman-git
pkgver=AUTO
...
source=(git://projects.archlinux.org/users/allan/pacman.git)
_git_branch="working"
_git_commit="8c857343"

build()
{
  cd $srcdir/pacman
  ./autogen.sh
  ...
}


What makepkg does:
1) goes into $vcsdir, checks for the pacman directory
   - if not present, do the git checkout
   - if present, enter and do a "git pull" unless --holdver is specified
2) enters $srcdir, and does the appropriate clone of the repo in $vscdir
to be at the required branch/tag/commit
3) starts build() etc...



Oh wow...  you are still reading this?   Well then, you are now
qualified to comment on the proposal.  Please stick to just concerns
with the git usage at the moment, unless you see something monumental
that we will not be able to support using other VCS systems using this
approach.

Allan