Am 13.03.2012 04:58, schrieb Allan McRae:
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. :)
Thank God - or Allan.
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.
One shortcoming: No way to use more than one git repo.
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
- More than one git repo per PKGBUILD (?)
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.
When using tarballs, we just extract them, and we don't care if two tarballs extract into the same directory. We should make this consistent (and thus equally stupid): If we check out pacman.git, call the directory pacman/. I didn't even know the :: syntax, but: The :: syntax is for downloaded file names, not for renaming the directory we extract into. For consistency, it should not be supported here.
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.
I am all for consistency here (again) - we allow multiple tarballs as source, so we should also allow multiple VCS repos as source. And this would force us to put the commit name into the URL in the source array. I don't see the real problem here, we could just have a nice syntax for git URLs. What would be the problem with $VCS:$URL@$COMMIT? GIT:git://projects.archlinux.org/pacman.git@maint SVN:ssh://svn.foo.com/bar@12345 It's readable and intuitive. (The @ might be a problem when you put user names in the URL, but we could just use @@ or so.)
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.
'git describe' is nice as it sorts well with vercmp (if the tag names are friendly enough). With my proposal about allowing arbitrarily many VCS sources, we should just make it a convention to use the first VCS source for the version - or make it configurable in pkgver.
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 ... }
Obviously, I don't like that, as pointed out above. I do like the pkgver=AUTO - makepkg should leave the pkgver alone if it isn't set to AUTO.
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
This should be a path under SRCDIR. This should also be a bare clone without working copy.
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...
ACK.
Oh wow... you are still reading this?
Hell yes!
Well then, you are now qualified to comment on the proposal.
Thanks, thou shallt not be disappointed.