Inconsistency of makepkg's activities in devel_check()

Waldteufel · 2009-08-16 18:02:17

Hello community.

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/Arc … 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/aldri … g/PKGBUILD, http://aur.archlinux.org/packages/audac … g/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() - rather not. 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 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 (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:

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 live_update() or something like this.

Any opinions?

Kind regards.
Waldteufel

PS: Apart from that, Arch is really nice. I Installed it a couple of weeks ago and it already became my favourite distribution

tomk · 2009-08-16 18:17:03

You should post this a feature request in the bugtracker, under the Pacman project, or else on the pacman-dev mailing list.

Waldteufel · 2009-08-16 18:29:37

I'll try the mailing list first. Thanks.

virus_found · 2009-09-28 12:08:34

I'm sorry, but is that weird behaviour ever going to be solved?

Allan · 2009-09-28 12:16:52

Well, not if it never makes it to the bug tracker.... or even the mailing list. This is the first I have seen of this issue and if no-one files a bug report, I will have forgotten by morning.

virus_found · 2009-09-28 13:42:01

Ok, here you are http://bugs.archlinux.org/task/16384 .
(It's the first bug I report, sorry, if something's wrong)

Allan · 2009-09-28 20:00:47

Thanks.

Arch Linux

#1 2009-08-16 18:02:17

Inconsistency of makepkg's activities in devel_check()

#2 2009-08-16 18:17:03

Re: Inconsistency of makepkg's activities in devel_check()

#3 2009-08-16 18:29:37

Re: Inconsistency of makepkg's activities in devel_check()

#4 2009-09-28 12:08:34

Re: Inconsistency of makepkg's activities in devel_check()

#5 2009-09-28 12:16:52

Re: Inconsistency of makepkg's activities in devel_check()

#6 2009-09-28 13:42:01

Re: Inconsistency of makepkg's activities in devel_check()

#7 2009-09-28 20:00:47

Re: Inconsistency of makepkg's activities in devel_check()

Board footer