[pacman-dev] Inconsistency of makepkg's activities in devel_check()
Hello developers. :-) I noticed that makepkg handles Mercurial repositories differently from CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using $(date ...) or retrieved from the online repository and the PKGBUILD is responsible for retrieving the contents as it is demonstrated here: http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines. Only with hg the repository is automatically cloned, pulled and updated: - - - - - makepkg, in devel_check(), lines 1211 and following - - - - - if [ -n "${_darcstrunk}" -a -n "${_darcsmod}" ] ; then [ $(type -p darcs) ] || return 0 msg "$(gettext "Determining latest darcs revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_cvsroot}" -a -n "${_cvsmod}" ] ; then [ $(type -p cvs) ] || return 0 msg "$(gettext "Determining latest cvs revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_gitroot}" -a -n "${_gitname}" ] ; then [ $(type -p git) ] || return 0 msg "$(gettext "Determining latest git revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_svntrunk}" -a -n "${_svnmod}" ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') elif [ -n "${_bzrtrunk}" -a -n "${_bzrmod}" ] ; then [ $(type -p bzr) ] || return 0 msg "$(gettext "Determining latest bzr revision...")" newpkgver=$(bzr revno ${_bzrtrunk}) elif [ -n "${_hgroot}" -a -n "${_hgrepo}" ] ; then [ $(type -p hg) ] || return 0 msg "$(gettext "Determining latest hg revision...")" if [ -d ./src/$_hgrepo ] ; then cd ./src/$_hgrepo hg pull hg update else [[ ! -d ./src/ ]] && mkdir ./src/ hg clone $_hgroot/$_hgrepo ./src/$_hgrepo cd ./src/$_hgrepo fi newpkgver=$(hg tip --template "{rev}") cd ../../ fi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This behaviour seems to be widely unknown, which leads to a lot of PKGBUILDS pulling/updating twice - first automatically and then again in build(): http://aur.archlinux.org/packages/aldrin-hg/aldrin-hg/PKGBUILD http://aur.archlinux.org/packages/audacious-hg/audacious-hg/PKGBUILD ... I just wonder why hg is handled differently and whether it wouldn't be better a) also to clone/update/pull/... svn/bzr/cvs/etc. in devel_check() - cf. http://wiki.archlinux.org/index.php/The_Arch_Way regarding automation or b) to remove devel_check() entirely, but leave devel_update() and let the PKGBUILD handle such changes, eg. like this: - - - complete example PKGBUILD in case anyone wants to try it - - - # Contributor: Artyom Smirnov <smirnoffjr@gmail.com> # Contributor: Benjamin Richter <webmaster@waldteufel-online.net> pkgname=gajim-hg pkgver=10960 pkgrel=1 pkgdesc="Jabber/XMMP instant messenger client written in PyGTK" arch=('i686' 'x86_64') url="http://gajim.org" license=('GPL') depends=('python>=2.5' 'pygtk>=2.12' 'sqlite3' 'dnsutils') makedepends=('python>=2.5' 'pygtk>=2.12' 'gtk2' 'libxss' 'dbus' 'gtkspell' 'intltool>=0.40.1' 'automake>=1.8' 'autoconf>=2.59' 'libtool' 'pkgconfig>=0.19') optdepends=('pyopenssl: secure SSL/TLS' 'pycrypto: End to end encryption' 'dbus-glib: link-local messaging (install python-avahi!)' 'python-avahi: link-local messaging (install dbus-glib!)' 'dnsutils: SRV support' 'gtkspell: Spell checking (install aspell-LANG!)' 'gnome-python-extras: GNOME integration' 'gnome-python-desktop: Keyring support' 'python-notify: Notification popups' 'dbus-python' 'python-sexy: for clickable URLs' 'python-kerberos>=1.1: GSSAPI authentication') provides=('gajim') conflicts=('gajim' 'gajim-svn') options=(!libtool) source=() md5sums=() scm_hg() { [[ -d "$2" ]] || hg clone "$1" "$2" || return cd "$2" ; hg pull -u || return newpkgver=$(hg tip --template '{rev}') } scm_retrieve() { [[ -z "$REPO_LATEST" ]] || return 0 export REPO_LATEST=1 msg "$(gettext "Determining latest $1 revision...")" cd "${srcdir}" "scm_${1}" "$2" "$3" msg2 "$(gettext 'Version found: %s')" "${newpkgver}" cd "${startdir}" devel_update } scm_retrieve hg http://hg.gajim.org/gajim gajim build() { cp -al gajim gajim-build cd gajim-build ./autogen.sh || return ./configure --prefix=/usr || return make || return make DESTDIR="${pkgdir}" install || return cd .. rm -r gajim-build find "${pkgdir}/usr/share/gajim/" -name "*.pyo" | xargs rm } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - cf. http://wiki.archlinux.org/index.php/The_Arch_Way regarding freedom (in this case: ... of the PKGBUILDer to choose by which means to retrieve sources under SCM) btw.: This latter approach already works without any change in makepkg. The question is whether it is advisable, especially because there is code outside build() which is run when the PKGBUILD is sourced, which happens twice because of fakeroot. This is why this PKGBUILD needs either the variable $REPO_LATEST or a rather ugly check whether makepkg is running in fakeroot (INFAKEROOT=1), which I'd rather not use because $INFAKEROOT is more like an implementation detail of makepkg. All this could be avoided by introducing another function - eg. update() - into the PKGBUILD which is run only once - that is: after sourcing the PKGBUILD when outside fakeroot - and sets $newpkgver, which would then be read by devel_update, which would be called after update() automatically. Makepkg would detect the existence of a function called update() and display the appropriate messages - eg. "Updating PKGBUILD...". The PKGBUILD would then look like this - provided that update() is called in $srcdir: - - - - - - - - - - - - - - another example - - - - - - - - - - - - - - pkgname=gajim-hg #... variables as before update() { [[ -d gajim ]] || hg clone http://hg.gajim.org/gajim || return 1 hg pull -u -R gajim || return 1 newpkgver=$(hg tip --template '{rev}' -R gajim) } #... build() as before - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - update() could also be called scm_retrieve() or something like that. Any opinions? Kind regards. Benjamin Richter (aka Waldteufel)
Hello again. Here is a patch that implements the third approach (a function called "update"). I kept the rest of devel_check(), so you can test it without breaking support for other PKGBUILDS. Benjamin Richter - - - - - - 0001-makepkg-call-update-in-devel_check.patch - - - - - -
From 21ee2c4c75e7618b2d34057900e8112259e54c9c Mon Sep 17 00:00:00 2001 From: Benjamin Richter <webmaster@waldteufel-online.net> Date: Mon, 17 Aug 2009 13:09:54 +0200 Subject: [PATCH] makepkg: call update() in devel_check()
This allows the PKGBUILD to define a function update() which is called in devel_check(). Thus, svn/cvs/...-PKGBUILDS can specify by themselves how the package version should be computed and other SCM systems can be used easily. It is also possible to retrieve the latest revision in update() like it already happens with hg repositories when $_hgroot and $_hgrepo are set. Signed-off-by: Benjamin Richter <webmaster@waldteufel-online.net> --- scripts/makepkg.sh.in | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index daa9585..de51a22 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1208,7 +1208,12 @@ devel_check() { # number to avoid having to determine the version number twice. # Also do a brief check to make sure we have the VCS tool available. oldpkgver=$pkgver - if [ -n "${_darcstrunk}" -a -n "${_darcsmod}" ] ; then + if [ "$(type -t update)" == "function" ]; then + msg "$(gettext "Retrieving latest revision...")" + cd "$srcdir" + update + cd "$startdir" + elif [ -n "${_darcstrunk}" -a -n "${_darcsmod}" ] ; then [ $(type -p darcs) ] || return 0 msg "$(gettext "Determining latest darcs revision...")" newpkgver=$(date +%Y%m%d) -- 1.6.4
On Sun, Aug 16, 2009 at 8:58 PM, Benjamin Richter<webmaster@waldteufel-online.net> wrote:
Hello developers. :-)
I noticed that makepkg handles Mercurial repositories differently from CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using $(date ...) or retrieved from the online repository and the PKGBUILD is responsible for retrieving the contents as it is demonstrated here: http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines.
Only with hg the repository is automatically cloned, pulled and updated:
I noticed this inconsistency just recently looking at makepkg code, and I don't like it either. I quickly looked at your proposed solutions and I am not convinced (or maybe the first one a) ). My suggestions : 1) cloning in all cases (like a) ) one big? disadvantage is that all existing scm PKGBUILDs will have to be converted and I wonder if this method might be too restrictive in some cases, where someone want to clone a repo in a specific way. 2) removing hg / mercurial support This is the easiest one :D 3) implement a way to get the version with hg without cloning, like all other scm already have This is the nicest / most difficult (maybe impossible?) one :)
On Mon, Aug 17, 2009 at 9:40 AM, Xavier<shiningxc@gmail.com> wrote:
On Sun, Aug 16, 2009 at 8:58 PM, Benjamin Richter<webmaster@waldteufel-online.net> wrote:
Hello developers. :-)
I noticed that makepkg handles Mercurial repositories differently from CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using $(date ...) or retrieved from the online repository and the PKGBUILD is responsible for retrieving the contents as it is demonstrated here: http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines.
Only with hg the repository is automatically cloned, pulled and updated:
I noticed this inconsistency just recently looking at makepkg code, and I don't like it either. I quickly looked at your proposed solutions and I am not convinced (or maybe the first one a) ).
My suggestions : 1) cloning in all cases (like a) ) one big? disadvantage is that all existing scm PKGBUILDs will have to be converted and I wonder if this method might be too restrictive in some cases, where someone want to clone a repo in a specific way.
Someone just proposed a patch to actually make GIT more like Hg (http://bugs.archlinux.org/task/15895). I'm not a fan of needing a full clone to get a version, but we could make it a bit more structured and make a specific function like fetch() fire before we get a version number? We already have build() and package()... -Dan
Am Montag, den 17.08.2009, 16:40 +0200 schrieb Xavier:
2) removing hg / mercurial support This is the easiest one :D :-/
3) implement a way to get the version with hg without cloning, like all other scm already have This is the nicest / most difficult (maybe impossible?) one :) Indeed. It is nice. But not impossible :-D
newpkgver=$(hg incoming -n "${_hgroot}/${_hgrepo}" -l 1 --template '{rev}') The local repository has to be created first (hg init is sufficient, _no_ clone needed!) and this line has to be executed in the local repository. Benjamin Richter
Am Montag, den 17.08.2009, 22:56 +0200 schrieb Benjamin Richter:
newpkgver=$(hg incoming -n "${_hgroot}/${_hgrepo}" -l 1 --template '{rev}')
PS: Unfortunately this still downloads all changes (like clone) - it just throws them away :-(
Dan McGee wrote:
On Mon, Aug 17, 2009 at 9:40 AM, Xavier<shiningxc@gmail.com> wrote:
On Sun, Aug 16, 2009 at 8:58 PM, Benjamin Richter<webmaster@waldteufel-online.net> wrote:
Hello developers. :-)
I noticed that makepkg handles Mercurial repositories differently from CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using $(date ...) or retrieved from the online repository and the PKGBUILD is responsible for retrieving the contents as it is demonstrated here: http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines.
Only with hg the repository is automatically cloned, pulled and updated:
I noticed this inconsistency just recently looking at makepkg code, and I don't like it either. I quickly looked at your proposed solutions and I am not convinced (or maybe the first one a) ).
My suggestions : 1) cloning in all cases (like a) ) one big? disadvantage is that all existing scm PKGBUILDs will have to be converted and I wonder if this method might be too restrictive in some cases, where someone want to clone a repo in a specific way.
Someone just proposed a patch to actually make GIT more like Hg (http://bugs.archlinux.org/task/15895). I'm not a fan of needing a full clone to get a version, but we could make it a bit more structured and make a specific function like fetch() fire before we get a version number? We already have build() and package()...
And likely check() in the future... (http://bugs.archlinux.org/task/15145). Adding a fetch() function would allow us to easily fix FS#13727 (http://bugs.archlinux.org/task/13727), where devel_update() is run before checking makedepends. From experience, someone needs to provide a PKGBUILD prototype for us to discuss or this suggestion would go nowhere... Allan
On Tue, Aug 18, 2009 at 12:22 PM, Allan McRae<allan@archlinux.org> wrote:
And likely check() in the future... (http://bugs.archlinux.org/task/15145). Adding a fetch() function would allow us to easily fix FS#13727 (http://bugs.archlinux.org/task/13727), where devel_update() is run before checking makedepends. From experience, someone needs to provide a PKGBUILD prototype for us to discuss or this suggestion would go nowhere...
How do we deal with the newpkgver stuff? should the fetch function overrides pkgver itself or something? This is weird..
participants (4)
-
Allan McRae
-
Benjamin Richter
-
Dan McGee
-
Xavier