[pacman-dev] VCS-PKGBUILDs

[Xavier Chantry]

On Sun, Apr 18, 2010 at 5:39 AM, David Campbell <davekong at archlinux.us> wrote:
> Does anyone find it odd that the non-VCS PKGBUILDs explicitly check to
> make sure the sources have not changed and that the PKGBUILD someone uses is
> actually going to build the package the maintainer wrote it for, yet, VCS
> PKGBUILDs don't?
>
> VCS sources may change frequently, but this does not make them more secure and
> requiring of less scrutiny than non-VCS packages.  If anything, they probably
> should be more scrutinized, since it would be more likely for someone to make
> a troublesome commit than a troublesome official release.
>
> There is also the issue that by automatically grabbing new sources without
> completely updating the PKGBUILD, many PKGBUILD fields may be incorrect, not
> just the pkgver. If the license a package is released under changes, the
> PKGBUILD won't care, etc..
>
> Rather than making an often failed attempt to automatically update the pkgver
> and ignoring the rest of the PKGBUILD fields, why not have VCS PKGBUILDs behave
> more like all the other PKGBUILDs.  When PKGBUILD sources change, a maintainer
> should have to update the PKGBUILD and PKGBUILDs which try to build using
> sources that don't match the PKGBUILD should fail.
>
> Figuring out the best way to check sources for all VCSs may require some
> creativity, but at least git would be really simple: check the hash for the last
> commit.
>
> Also, instead of using the date for the pkgver field of a VCS PKGBUILD, have
> the pkgver reflect the most recent release that the given development package is
> based off of.  Then, use a commit field to show how many commits ahead of that
> release a package is.  These fields would make it more clear what exactly the
> PKGBUILD is a PKGBUILD for.  If there is no release to use commits since, the
> field could be left blank.  This avoids ambiguity caused by different sources of
> a development project being released on the same day as well as issues with the
> sometimes significant difference between when a commit is authored and actually
> committed.
> --
> David Campbell
>
>

A quick answer to say these are all good points imo.
However, the "automatic bump" is also a good feature to have. We
should have both and just decide for a default.

When makepkg started to bump automatically the version, some people
quickly reclaimed the need to hold the version, and that option was
introduced :
      --holdver    Prevent automatic version bumping for development PKGBUILDs

However this only works for cvs , which sets pkgver to a date and can
checkout a date, and svn which sets pkgver to a revision and can
checkout a revision.

The support for all VCS other than cvs and svn is desperately dumb.

The second biggest difference between cvs/svn and the rest, that
accounts for a lot of suckage with the other VCS, is the inability to
query remotely the latest revision/version. We need to download/pull
the code first.