On 13/03/12 20:25, Thomas Bächler wrote:
Am 13.03.2012 09:21, schrieb Allan McRae:
Is it at all feasible to just use the build date for package ordering if it's a vcs package? This way the pkgver can be the ref that was checked out:
- the short hash - the tag - the branch (_short hash maybe OR only automatically bump the pkgrel)
I would really like to move away from the build date having anything to do with package ordering as it is entirely non-deterministic about what is in a package.
I cannot ACK that enough. Please, no build dates!
source=(git://projects.archlinux.org/users/allan/pacman.git) _git_branch="working" _git_commit="8c857343"
Are these looking forward to other VCS's though? What scenario is more than one ref needed? Makepkg would just be doing a checkout right?
This might be me not understanding some of the subtleties of git, but this is what I see as options for building from a git repo...
1) build from master HEAD 2) build from a branch HEAD 3) build from a given commit/tag
So, assuming that the git repo is checked out from upstream in $vcsdir, the command needed for each of these is:
1) git clone --branch master $vcsdir [*] 2) git clone --branch <branch> $vcsdir 3) git clone $vcsdir; git checkout <ref>
You complicate things A LOT here. Specifying the branch and commit separately is nonsense. The commit id already tells you exactly where you want to be. This is the right thing to do:
Just to be clear, you do realize these are not three commands to be run one after the other but the way I was thinking about achieving each of the three usages scenarios I gave above?
$ git clone $vcsdir $ git checkout -b makepkg $ref
Here, $ref can be a tag name, a branch name, a commit id or an abbreviated commit id - everything git understands as a refspec. Let's just give git a single refspec and let it handle the rest.
(I just realized I might be slightly wrong here, as we refer to branch and tag names in a remote repository of a remote repository - but I am sure some magic exists here that will make it just as easy as I described, Dan probably knows.)
This is what you don't seem to understand: Once you have the commit id, the branch name has no relevance anymore. You only need the branch name when referencing the head of that branch.
I do understand the branch name is useless once you have a tag/commit id. That is why later in the email I said it only really serves as documentation. What I was trying to avoid is the need to specify (e.g.) "origin/maint" as the branch. The "origin/" part just seems redundant and the I was trying to remove as much redundancy across PKGBUILDs as possible here. Of course I also see that having separate methods to specify a branch and a ref/tag is redundant too... In the end there is probably no such thing as perfection here. Allan