[pacman-dev] [PATCH] Integrate versionpkg into makepkg
I personally found it silly to have separate scripts for makepkg and versionpkg. I've seen countless messages on AUR where people ask for -svn PKGBUILDS to be updated because their pkgver is out of date, etc. Many people don't know about versionpkg and, even if you do, it makes sense to have a single script that handles both. Please look at the patch carefully because I am by no means a shell scripting expert. I tested it with mpd-svn and mpd PKGBUILDS; both worked fine but that hardly means everything is perfect. Also, this removes the --check-only and --modify-only arguments that the standalone versionpkg script accepted. I guess there's no reason these can't be added back in, but they seem a little useless to me (and their short arguments, -c and -m, are already used by makepkg for other purposes). Scott --- /usr/bin/makepkg 2007-09-16 16:33:23.000000000 -0600 +++ /usr/bin/makepkg2 2007-10-26 13:07:52.000000000 -0600 @@ -34,6 +34,8 @@ source "/etc/abs/abs.conf" SRCROOT="$ABSROOT" +FORCE_VER="" + # Options CLEANUP=0 CLEANCACHE=0 @@ -106,6 +108,10 @@ echo "$1" | sed 's|^.*://.*/||g' } +update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} + # checks to see if options are present in makepkg.conf or PKGBUILD; # PKGBUILD options always take precedence check_option() { @@ -457,7 +463,7 @@ exit 1 ;; -*) - while getopts "bcCdefghiLmop:rRsS-" opt; do + while getopts "bcCdefghiLmopz:rRsS-" opt; do case $opt in b) DEP_SRC=1 ;; c) CLEANUP=1 ;; @@ -479,6 +485,7 @@ R) REPKG=1 ;; s) DEP_BIN=1 ;; S) SUDO=1 ;; + z) FORCE_VER=$OPTARG ;; -) OPTIND=0 break @@ -592,6 +599,67 @@ fi fi +newpkgver="" +if [ "$FORCE_VER" = "" ]; then + # Check if this is a svn/cvs/etc PKGBUILD; set $newpkgver if so. + # This will only be used on the first call to makepkg; subsequent + # calls to makepkg via fakeroot will explicitly pass the version + # number to avoid having to determine the version number twice. + oldpkgver=$pkgver + if [ ! -z ${_darcstrunk} ] && [ ! -z ${_darcsmod} ] ; then + msg "determining latest darcs revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver + elif [ ! -z ${_cvsroot} ] && [ ! -z ${_cvsmod} ] ; then + msg "determining latest cvs revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver + elif [ ! -z ${_gitroot} ] && [ ! -z ${_gitname} ] ; then + msg "determining latest git revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver + elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then + msg "retrieving latest revision number from svn... \c" + newpkgver=$(svn log $_svntrunk --limit 1 | sed -n 's/^r\([^ ]*\) .*$/\1/p') + echo "$newpkgver" + elif [ ! -z ${_bzrtrunk} ] && [ ! -z ${_bzrmod} ] ; then + msg "retrieving latest revision number from bzr... \c" + newpkgver=$(bzr revno ${_bzrtrunk}) + echo "$newpkgver" + elif [ ! -z ${_hgroot} ] && [ ! -z ${_hgrepo} ] ; then + if [ -d ./src/$_hgrepo ] ; then + msg "retrieving latest revision number from hg... \c" + cd ./src/$_hgrepo + make clean + hg pull + hg update + else + msg "determining latest hg revision... \c" + [[ ! -d ./src/$_hgrepo ]] && mkdir -p ./src/$_hgrepo + hg clone $_hgroot/$_hgrepo ./src/$_hgrepo + cd ./src/$_hgrepo + fi + newpkgver=$(hg tip | sed -n '1s/[^0-9]*\([^:]*\):.*$/\1/p') + echo "$newpkgver" + cd ../../ + fi + + if [ "$newpkgver" != "$oldpkgver" ]; then + msg "newer revision detected: $newpkgver" + elif [ "$newpkgver" != "" ]; then + warning "PKGBUILD pkgver is $oldpkgver, no newer revision available" + if [ "$FORCE" = "1" ]; then + msg "forcing pkgver to $newpkgver... " + else + error "exiting now, use makepkg -f to force update" + exit 1 + fi + fi +else + # Version number retrieved from fakeroot->makepkg argument + newpkgver=$FORCE_VER +fi + # Enter the fakeroot environment if necessary. This will call the makepkg # script again as the fake root user. We detect this by passing a sentinel # option (-F) to makepkg. @@ -599,7 +667,11 @@ if [ "$(check_buildenv fakeroot)" = "y" ]; then if [ $(type -p fakeroot) ]; then msg "Entering fakeroot environment" - fakeroot -- $0 -F $ARGLIST + if [ "$newpkgver" != "" ]; then + fakeroot -- $0 -F $ARGLIST -z $newpkgver + else + fakeroot -- $0 -F $ARGLIST + fi exit $? else warning "Fakeroot is not installed. Building as an unprivileged user" @@ -617,6 +689,18 @@ fi fi +# This is lame, but if we're wanting to use an updated pkgver for +# retrieving svn/cvs/etc sources, we'll update the PKGBUILD, re-source +# it, and then revert it +if [ "$newpkgver" != "" ]; then + if [ "newpkgver" != "$pkgver" ]; then + oldpkgver=$pkgver + update_pb $newpkgver + source $BUILDSCRIPT + update_pb $oldpkgver + fi +fi + msg "Making package: $pkgname $pkgver-$pkgrel ($(date))" # fix flyspray bug #5973
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
I personally found it silly to have separate scripts for makepkg and versionpkg. I've seen countless messages on AUR where people ask for -svn PKGBUILDS to be updated because their pkgver is out of date, etc. Many people don't know about versionpkg and, even if you do, it makes sense to have a single script that handles both.
Please look at the patch carefully because I am by no means a shell scripting expert. I tested it with mpd-svn and mpd PKGBUILDS; both worked fine but that hardly means everything is perfect.
Great idea. Personally, I've never looked at versionpkg, but I did like the functionality of it. I only have a few comments, which are probably more directed at versionpkg itself.
+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +
The 1,11 scares me here. It seems kinda arbitrary. To me this seems better: sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT But might also fail. I don't know, but the 1,11 choice is off-putting to me.
+# This is lame, but if we're wanting to use an updated pkgver for +# retrieving svn/cvs/etc sources, we'll update the PKGBUILD, re-source +# it, and then revert it +if [ "$newpkgver" != "" ]; then + if [ "newpkgver" != "$pkgver" ]; then + oldpkgver=$pkgver + update_pb $newpkgver + source $BUILDSCRIPT + update_pb $oldpkgver + fi +fi +
Hmmm this scares me too. HOWEVER, if we're going to do this, wouldn't it be smarter to actually NOT revert to the old version and maybe output something?
On 10/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I only have a few comments, which are probably more directed at versionpkg itself.
+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +
The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:
sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT
But might also fail. I don't know, but the 1,11 choice is off-putting to me.
How might it fail? And yes, that function is pretty much directly from versionpkg..
+# This is lame, but if we're wanting to use an updated pkgver for +# retrieving svn/cvs/etc sources, we'll update the PKGBUILD, re-source +# it, and then revert it +if [ "$newpkgver" != "" ]; then + if [ "newpkgver" != "$pkgver" ]; then + oldpkgver=$pkgver + update_pb $newpkgver + source $BUILDSCRIPT + update_pb $oldpkgver + fi +fi +
Hmmm this scares me too. HOWEVER, if we're going to do this, wouldn't it be smarter to actually NOT revert to the old version and maybe output something?
I don't mind if we don't revert it, but versionpkg currently reverts it. There certainly seems to be no harm in not reverting it... I don't think there's any alternative to updating the PKGBUILD and re-sourcing it because you can have something like the mpd-svn PKGBUILD where: pkgver=4596 ... _revnumber=$pkgver If not for this kind of strangeness/stupidity, you could easily just set pkgver in makepkg itself... Also, I've attached the patch because some of the lines were too long and wrapped.. Scott
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 10/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I only have a few comments, which are probably more directed at versionpkg itself.
+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +
The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:
sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT
But might also fail. I don't know, but the 1,11 choice is off-putting to me.
How might it fail? And yes, that function is pretty much directly from versionpkg..
If the pkgver is not in the first 11 lines of the PKGBUILD? It seems pretty arbitrary for versionpkg to enforce that.
On 10/26/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 10/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I only have a few comments, which are probably more directed at versionpkg itself.
+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +
The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:
sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT
But might also fail. I don't know, but the 1,11 choice is off-putting to me.
How might it fail? And yes, that function is pretty much directly from versionpkg..
If the pkgver is not in the first 11 lines of the PKGBUILD? It seems pretty arbitrary for versionpkg to enforce that.
Oh sorry, I meant to ask how it might fail if you removed that first 11 lines part. Aaron said "But might also fail?" to his own line. And I'm not suggesting it won't, I'm more curious than anything. Scott
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 10/26/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 10/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I only have a few comments, which are probably more directed at versionpkg itself.
+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +
The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:
sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT
But might also fail. I don't know, but the 1,11 choice is off-putting to me.
How might it fail? And yes, that function is pretty much directly from versionpkg..
If the pkgver is not in the first 11 lines of the PKGBUILD? It seems pretty arbitrary for versionpkg to enforce that.
Oh sorry, I meant to ask how it might fail if you removed that first 11 lines part. Aaron said "But might also fail?" to his own line. And I'm not suggesting it won't, I'm more curious than anything.
By "fail" in MY example, I meant that it will rewrite any pkgver=X that starts at column 0.... so it could brake things like: build() { ./configure --version \ pkgver=1 make } and WON'T work with any space in front of pkgver. Still, it's a better metric than the 11 line one
On 10/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
that starts at column 0.... so it could brake things like: break*
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
I personally found it silly to have separate scripts for makepkg and versionpkg. I've seen countless messages on AUR where people ask for -svn PKGBUILDS to be updated because their pkgver is out of date, etc. Many people don't know about versionpkg and, even if you do, it makes sense to have a single script that handles both.
Please look at the patch carefully because I am by no means a shell scripting expert. I tested it with mpd-svn and mpd PKGBUILDS; both worked fine but that hardly means everything is perfect.
Also, this removes the --check-only and --modify-only arguments that the standalone versionpkg script accepted. I guess there's no reason these can't be added back in, but they seem a little useless to me (and their short arguments, -c and -m, are already used by makepkg for other purposes).
Scott
Hate to stomp on good ideas, but can you port this patch to the current GIT version of makepkg? I really like it because it doesn't seem to do too much, but makepkg has changed a lot since pacman 3.0.0. If you need any help with git, try to catch me on IRC or send me a private email. One thought- usage instructions would be nice to be in the patch too (the stuff from makepkg --help). -Dan
Hate to stomp on good ideas, but can you port this patch to the current GIT version of makepkg? I really like it because it doesn't seem to do too much, but makepkg has changed a lot since pacman 3.0.0.
Ok, attached is a patch against makepkg in git. It uses Aaron's sed line and is simplified a bit from my previous patch.
One thought- usage instructions would be nice to be in the patch too (the stuff from makepkg --help).
I'm not sure what you mean? There aren't any usage instructions, it doesn't add any public arguments. If it finds the correct svn/etc variables in the PKGBUILD, it'll update to the latest revision. (Behind the scenes, I do use a -z argument to prevent the revision number from being searched for twice due to fakeroot's makepkg call...) It also fixes a small typo ;-) And finally, makepkg -p seems to be documented, but the argument doesn't appear to be valid anymore (it's not parsed). I'm not sure if your intention was to remove that option or it's simply an oversight... Scott
On 10/26/07, Scott Horowitz <stonecrest@gmail.com> wrote:
Hate to stomp on good ideas, but can you port this patch to the current GIT version of makepkg? I really like it because it doesn't seem to do too much, but makepkg has changed a lot since pacman 3.0.0.
Ok, attached is a patch against makepkg in git. It uses Aaron's sed line and is simplified a bit from my previous patch.
One thought- usage instructions would be nice to be in the patch too (the stuff from makepkg --help).
I'm not sure what you mean? There aren't any usage instructions, it doesn't add any public arguments. If it finds the correct svn/etc variables in the PKGBUILD, it'll update to the latest revision. (Behind the scenes, I do use a -z argument to prevent the revision number from being searched for twice due to fakeroot's makepkg call...)
Ahh, one of those hidden options. Comments below on that.
It also fixes a small typo ;-)
And finally, makepkg -p seems to be documented, but the argument doesn't appear to be valid anymore (it's not parsed). I'm not sure if your intention was to remove that option or it's simply an oversight...
Fixed on my working branch, it looks like it was an oversight in the getopt conversion. I've repasted your patch below to give a few comments. Overall looks pretty good though. I am going to have to ask you for one thing: http://archlinux.org/pipermail/pacman-dev/2007-October/009681.html This should help you make a patch: http://wiki.archlinux.org/index.php/Super_Quick_Git_Guide For everyone: to make a patch, just start your own branch based off of master (git checkout -b mybranch master), make your changes, and use the poor man's way of committing everything (git commit -a -s). Then type 'git-format-patch master' and you'll produce a stupendous patch. (Note: you may want to do 'git-config --global user.name "My Name"' and git-config --global user.email "myemail@domain.com"' to make your signoff and author lines correct.) -Dan --- pacman/scripts/makepkg.sh.in 2007-10-26 16:05:33.000000000 -0600 +++ makepkg.sh.in 2007-10-26 15:59:50.000000000 -0600 @@ -60,6 +60,8 @@ SOURCEONLY=0 IGNOREARCH=0 +FORCE_VER="" ***Perhaps a comment here stating what this var is used for? + PACMAN_OPTS= ### SUBROUTINES ### @@ -976,6 +978,72 @@ fi } +devel_check() { + newpkgver="" + if [ "$FORCE_VER" = "" ]; then + # Check if this is a svn/cvs/etc PKGBUILD; set $newpkgver if so. + # This will only be used on the first call to makepkg; subsequent + # calls to makepkg via fakeroot will explicitly pass the version + # number to avoid having to determine the version number twice. + oldpkgver=$pkgver + if [ ! -z ${_darcstrunk} ] && [ ! -z ${_darcsmod} ] ; then + msg "$(gettext "Determining latest darcs revision...")" + newpkgver=$(date +%Y%m%d) + elif [ ! -z ${_cvsroot} ] && [ ! -z ${_cvsmod} ] ; then + msg "$(gettext "Determining latest cvs revision...")" + newpkgver=$(date +%Y%m%d) + elif [ ! -z ${_gitroot} ] && [ ! -z ${_gitname} ] ; then + msg "$(gettext "Determining latest git revision...")" + newpkgver=$(date +%Y%m%d) + elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then + msg "$(gettext "Determining latest svn revision...")" + newpkgver=$(svn log $_svntrunk --limit 1 | sed -n 's/^r\([^ ]*\) .*$/\1/p') + elif [ ! -z ${_bzrtrunk} ] && [ ! -z ${_bzrmod} ] ; then + msg "$(gettext "Determining latest bzr revision...")" + newpkgver=$(bzr revno ${_bzrtrunk}) + elif [ ! -z ${_hgroot} ] && [ ! -z ${_hgrepo} ] ; then + msg "$(gettext "Determining latest hg revision...")" + if [ -d ./src/$_hgrepo ] ; then + cd ./src/$_hgrepo + make clean + hg pull + hg update + else + [[ ! -d ./src/$_hgrepo ]] && mkdir -p ./src/$_hgrepo + hg clone $_hgroot/$_hgrepo ./src/$_hgrepo + cd ./src/$_hgrepo + fi + newpkgver=$(hg tip | sed -n '1s/[^0-9]*\([^:]*\):.*$/\1/p') + cd ../../ + fi + + if [ "$newpkgver" != "" ]; then + msg2 "$(gettext "Version found: %s")" "$newpkgver" + pkgver=$newpkgver + fi + + else + # Version number retrieved from fakeroot->makepkg argument + newpkgver=$FORCE_VER + fi +} ***Trusting that this code is good, it looks sane to me. + +devel_update() { + # This is lame, but if we're wanting to use an updated pkgver for + # retrieving svn/cvs/etc sources, we'll update the PKGBUILD with + # the new pkgver and then re-source it. This is the most robust + # method for dealing with PKGBUILDs that use, e.g.: + # pkgver=23 + # ... + # _foo=pkgver + if [ "$newpkgver" != "" ]; then + if [ "newpkgver" != "$pkgver" ]; then + sed -i "s/^pkgver=[^ ]*/pkgver=$newpkgver/" ./$BUILDSCRIPT + source $BUILDSCRIPT + fi + fi +} + usage() { printf "makepkg (pacman) %s\n" "$myver" echo @@ -1058,7 +1126,7 @@ fi # Parse Command Line Options. -OPT_SHORT="AbcCdefFghiLmop:rRsSV" +OPT_SHORT="AbcCdefFghiLmopz:rRsSV" OPT_LONG="ignorearch,asroot,builddeps,clean,cleancache,nodeps,noextract,force,geninteg,help,install,log" OPT_LONG="$OPT_LONG,nocolor,nobuild,rmdeps,repackage,source,syncdeps,usesudo,version" # Pacman Options @@ -1096,6 +1164,7 @@ -R|--repackage) REPKG=1 ;; --source) SOURCEONLY=1 ;; -s|--syncdeps) DEP_BIN=1 ;; + -z) shift; FORCE_VER=$1;; ****Can you stick a comment above this parameter saying it is a hidden argument and what it is for? It might even be better to use a long option since we don't really care who has to type it- it is better to be descriptive and this way we aren't using up one of our few remaining short options. # BEGIN DEPRECATED -S|--usesudo) @@ -1255,12 +1324,15 @@ fi fi -# Run the bear minimum in fakeroot +devel_check + +# Run the bare minimum in fakeroot # fix flyspray bug 6208 -- using makepkg with fakeroot gives an error if [ "$INFAKEROOT" = "1" ]; then if [ "$REPKG" = "1" ]; then warning "$(gettext "Skipping build.")" else + devel_update run_build tidy_install fi @@ -1359,6 +1431,7 @@ if [ "$REPKG" = "1" ]; then warning "$(gettext "Skipping build.")" else + devel_update run_build tidy_install fi @@ -1368,7 +1441,11 @@ msg "$(gettext "Entering fakeroot environment...")" cd "$startdir" - fakeroot -- $0 -F $ARGLIST || exit $? + if [ "$newpkgver" != "" ]; then + fakeroot -- $0 -z $newpkgver -F $ARGLIST || exit $? + else + fakeroot -- $0 -F $ARGLIST || exit $? + fi fi create_xdelta "$PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}"
Ok, try this out.. git patch is attached to prevent wrapping issues. Scott
Scott Horowitz wrote:
Ok, try this out.. git patch is attached to prevent wrapping issues.
Scott
Applied to my working tree. -Dan
Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line. See: http://bugs.archlinux.org/task/7606 and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon) Scott
On Oct 30, 2007 2:54 AM, Scott Horowitz <stonecrest@gmail.com> wrote:
Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line.
See: http://bugs.archlinux.org/task/7606
and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon)
Scott
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
The bug filed is only due to the src directory not being there. I don't know how creating the $_hgrepo directory solved the problem, since mercurial simply doesn't support initting or cloning a repo to a directory that exists. A proper solution would be to create the src directory if it doesn't exist, or wrap the whole path with dirname to remove the last directory.
On Oct 30, 2007 11:28 PM, Xilon <xilonmu@gmail.com> wrote:
On Oct 30, 2007 2:54 AM, Scott Horowitz <stonecrest@gmail.com> wrote:
Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line.
See: http://bugs.archlinux.org/task/7606
and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon)
Scott
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
The bug filed is only due to the src directory not being there. I don't know how creating the $_hgrepo directory solved the problem, since mercurial simply doesn't support initting or cloning a repo to a directory that exists. A proper solution would be to create the src directory if it doesn't exist, or wrap the whole path with dirname to remove the last directory.
Here's a patch which should fix both issues, though I haven't run into the other one mention for which a bug was filled, so I was unable to test it. I have tested the patch for subtle-hg and abraca-hg, both cloning and updating works. I also removed the pointless "make clean", the PKGBUILDs should be building in another directory anyway, as the guidelines suggest.
On Nov 5, 2007 1:56 AM, Xilon <xilonmu@gmail.com> wrote:
On Oct 30, 2007 11:28 PM, Xilon <xilonmu@gmail.com> wrote:
On Oct 30, 2007 2:54 AM, Scott Horowitz <stonecrest@gmail.com> wrote:
Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line.
See: http://bugs.archlinux.org/task/7606
and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon)
Scott
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
The bug filed is only due to the src directory not being there. I don't know how creating the $_hgrepo directory solved the problem, since mercurial simply doesn't support initting or cloning a repo to a directory that exists. A proper solution would be to create the src directory if it doesn't exist, or wrap the whole path with dirname to remove the last directory.
Here's a patch which should fix both issues, though I haven't run into the other one mention for which a bug was filled, so I was unable to test it. I have tested the patch for subtle-hg and abraca-hg, both cloning and updating works. I also removed the pointless "make clean", the PKGBUILDs should be building in another directory anyway, as the guidelines suggest.
Thanks for this, I've pulled it into my working branch. And good catch with the "make clean"- we should never do that in makepkg. -Dan
On Fri, Oct 26, 2007 at 01:12:47PM -0600, Scott Horowitz <stonecrest@gmail.com> wrote:
+ if [ ! -z ${_darcstrunk} ] && [ ! -z ${_darcsmod} ] ; then + msg "determining latest darcs revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver + elif [ ! -z ${_cvsroot} ] && [ ! -z ${_cvsmod} ] ; then + msg "determining latest cvs revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver + elif [ ! -z ${_gitroot} ] && [ ! -z ${_gitname} ] ; then + msg "determining latest git revision... \c" + newpkgver=$(date +%Y%m%d) + echo $newpkgver
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated like: date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`' and lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p' more examples here: http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=blob;... - VMiklos
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated
like:
date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'
and
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
On 10/29/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated
like:
date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'
and
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
Well if I use a git:// address in my PKGBUILD, then yeah, this method screws us. Did we really think the git tools wouldn't do there job? The only reason I didn't do this before is because I was just accepting it the way it currently works for versionpkg, although now might be the time to make this change. The following will take ANY GIT repo url (local FS, http://, git://, etc) and produce a nice pretty version name for you. git-ls-remote $_gitroot $_gitname | git-describe Example: $git ls remote git://projects.archlinux.org/pacman.git master | git-describe v3.0.0-497-g014306e Now that wasn't too hard, now was it? The only problem is that git-describe uses '-' characters in its version. Do we allow this, or is that reserved as a seperator for the pkgrel? I know there are some funny parsing issues we have to make sure we do right. -Dan diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 831c1bd..5de7205 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -996,7 +996,7 @@ devel_check() { newpkgver=$(date +%Y%m%d) elif [ ! -z ${_gitroot} ] && [ ! -z ${_gitname} ] ; then msg "$(gettext "Determining latest git revision...")" - newpkgver=$(date +%Y%m%d) + newpkgver=$(git-ls-remote ${_gitroot} ${_gitname} | git-describe) elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then msg "$(gettext "Determining latest svn revision...")" newpkgver=$(svn log $_svntrunk --limit 1 | sed -n 's/^r\([^ ]*\) .*$/\1/p')
2007/10/29, Dan McGee <dpmcgee@gmail.com>:
On 10/29/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated
like:
date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'
and
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
Well if I use a git:// address in my PKGBUILD, then yeah, this method screws us.
Did we really think the git tools wouldn't do there job? The only reason I didn't do this before is because I was just accepting it the way it currently works for versionpkg, although now might be the time to make this change.
The following will take ANY GIT repo url (local FS, http://, git://, etc) and produce a nice pretty version name for you.
git-ls-remote $_gitroot $_gitname | git-describe
Example: $git ls remote git://projects.archlinux.org/pacman.git master | git-describe v3.0.0-497-g014306e
Now that wasn't too hard, now was it? The only problem is that git-describe uses '-' characters in its version. Do we allow this, or is that reserved as a seperator for the pkgrel? I know there are some funny parsing issues we have to make sure we do right.
I think '-' should not be allowed. It can be replaced with '_'. -- Roman Kyrylych (Роман Кирилич)
On 10/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/10/29, Dan McGee <dpmcgee@gmail.com>:
On 10/29/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated
like:
date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'
and
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
Well if I use a git:// address in my PKGBUILD, then yeah, this method screws us.
Did we really think the git tools wouldn't do there job? The only reason I didn't do this before is because I was just accepting it the way it currently works for versionpkg, although now might be the time to make this change.
The following will take ANY GIT repo url (local FS, http://, git://, etc) and produce a nice pretty version name for you.
git-ls-remote $_gitroot $_gitname | git-describe
Example: $git ls remote git://projects.archlinux.org/pacman.git master | git-describe v3.0.0-497-g014306e
Now that wasn't too hard, now was it? The only problem is that git-describe uses '-' characters in its version. Do we allow this, or is that reserved as a seperator for the pkgrel? I know there are some funny parsing issues we have to make sure we do right.
I think '-' should not be allowed. It can be replaced with '_'.
I did forget to note as well- you have to have a local copy of the repo before you can run git-describe, so that may rule its usage out. -Dan
On Mon, Oct 29, 2007 at 11:47:40AM -0500, Aaron Griffin wrote:
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated
like:
date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'
and
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
If I'm not mistaken the main darcs interface is http. The only other way to interact with it is over ssh. So this will probably work for darcs. Jason
On 10/29/07, Jason Chu <jason@archlinux.org> wrote:
On Mon, Oct 29, 2007 at 11:47:40AM -0500, Aaron Griffin wrote:
On 10/27/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
If I'm not mistaken the main darcs interface is http. The only other way to interact with it is over ssh. So this will probably work for darcs.
I refuse to add lynx as a dependency for makepkg. If it can't be done KISS, today's date works fine for me for a version number. -Dan
On Mon, Oct 29, 2007 at 11:47:40AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?
right, for git this won't work for git://. for darcs, http is the primary anonymous transport, so it will work i think - VMiklos
participants (7)
-
Aaron Griffin
-
Dan McGee
-
Jason Chu
-
Miklos Vajna
-
Roman Kyrylych
-
Scott Horowitz
-
Xilon