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

[Allan McRae]

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