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

[Thomas Bächler]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20120313/992c378a/attachment-0001.asc>