[pacman-dev] makepkg -w argument removed?
I'm just curious why the -w argument was removed from makepkg? It apparently was removed in rev 1.23: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/scripts/makepkg.diff?r1=1.22&r2=1.23&cvsroot=Pacman I know that aurbuild is currently making use of it, for example. Scott
On 1/21/07, Scott Horowitz <stonecrest@gmail.com> wrote:
I'm just curious why the -w argument was removed from makepkg? It apparently was removed in rev 1.23:
I know that aurbuild is currently making use of it, for example.
Here is the most applicable list posting I can find about it: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000842.html I think we had been discussing how many options makepkg had grown to, and wanted to cut some of them out. We removed the package specific options that can be set in a PKGBUILD. We also decided to remove the two storage directory parameters because they didn't seem necessary. Can the aurbuild script not simply perform a makepkg followed by a cp or mv operation? The biggest problem to this is that a user can set a custom location to build their packages to, in which case the aurbuild script will probably fail. However, scripts can source makepkg.conf and find out where packages are destined for. Both makepkg 2.9.8 and makepkg 3 have 21 command line options, so adding more just makes the script that much more complex. Feel free to bring up some counterpoints, these are just my thoughts on the issue. -Dan -Dan
On Sun, 21 Jan 2007 17:31:52 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 1/21/07, Scott Horowitz <stonecrest@gmail.com> wrote:
I'm just curious why the -w argument was removed from makepkg? It apparently was removed in rev 1.23:
I know that aurbuild is currently making use of it, for example.
Here is the most applicable list posting I can find about it: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000842.html
I think we had been discussing how many options makepkg had grown to, and wanted to cut some of them out. We removed the package specific options that can be set in a PKGBUILD. We also decided to remove the two storage directory parameters because they didn't seem necessary. Can the aurbuild script not simply perform a makepkg followed by a cp or mv operation? The biggest problem to this is that a user can set a custom location to build their packages to, in which case the aurbuild script will probably fail. However, scripts can source makepkg.conf and find out where packages are destined for.
Both makepkg 2.9.8 and makepkg 3 have 21 command line options, so adding more just makes the script that much more complex.
Feel free to bring up some counterpoints, these are just my thoughts on the issue.
-Dan
I always thought if there's an option that can be set in makepkg.conf, there should be a corresponding command line option to a) disable a set makepkg.conf option one time or b) set it to something it's not usually set to one time. If there were no makepkg.conf option, then I wouldn't see a problem, but because you can do it in the global case, you should be able to modify it in the single case. Jason
On 1/22/07, Jason Chu <jason@archlinux.org> wrote:
I always thought if there's an option that can be set in makepkg.conf, there should be a corresponding command line option to a) disable a set makepkg.conf option one time or b) set it to something it's not usually set to one time.
If there were no makepkg.conf option, then I wouldn't see a problem, but because you can do it in the global case, you should be able to modify it in the single case.
Jason
Other options, sure, but we just figured it was quite confusing to have an option that puts a package in one place one time- would you ever do this on a "regular" basis? Obviously aurbuild does, but would a human user, so to speak, do so? How about this, and correct me if it isn't possible. What if aurbuild sets the PKGDEST variable itself before invoking makepkg, and sets it using readonly (man readonly)? I believe this would work, but haven't tested it enough. -Dan
On Mon, 22 Jan 2007 12:09:24 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 1/22/07, Jason Chu <jason@archlinux.org> wrote:
I always thought if there's an option that can be set in makepkg.conf, there should be a corresponding command line option to a) disable a set makepkg.conf option one time or b) set it to something it's not usually set to one time.
If there were no makepkg.conf option, then I wouldn't see a problem, but because you can do it in the global case, you should be able to modify it in the single case.
Jason
Other options, sure, but we just figured it was quite confusing to have an option that puts a package in one place one time- would you ever do this on a "regular" basis? Obviously aurbuild does, but would a human user, so to speak, do so?
How about this, and correct me if it isn't possible. What if aurbuild sets the PKGDEST variable itself before invoking makepkg, and sets it using readonly (man readonly)? I believe this would work, but haven't tested it enough.
-Dan
I would say the most common case is a script setting it, that's true. How about I rephrase a bit: There must be a way that does not involve changing any files on the filesystem to modify this option in the one time case. If there is a way other than a command line option, that's fine. I was thinking about using the -w option to save all my rebuilt packages for python25 into a repo directory so that I could easily rebuild the db without having to track down all the packages. I wouldn't be using this repo directory for building any packages not for python25. Jason
On Sun, Jan 21, 2007 at 05:31:52PM -0500, Dan McGee wrote:
On 1/21/07, Scott Horowitz <stonecrest@gmail.com> wrote:
I'm just curious why the -w argument was removed from makepkg? It apparently was removed in rev 1.23:
I know that aurbuild is currently making use of it, for example.
Here is the most applicable list posting I can find about it: http://www.archlinux.org/pipermail/pacman-dev/2006-December/000842.html
I think we had been discussing how many options makepkg had grown to, and wanted to cut some of them out. We removed the package specific options that can be set in a PKGBUILD. We also decided to remove the two storage directory parameters because they didn't seem necessary. Can the aurbuild script not simply perform a makepkg followed by a cp or mv operation? The biggest problem to this is that a user can set a custom location to build their packages to, in which case the aurbuild script will probably fail. However, scripts can source makepkg.conf and find out where packages are destined for.
Both makepkg 2.9.8 and makepkg 3 have 21 command line options, so adding more just makes the script that much more complex.
makepkg could use environment variables customized by the user: PKGDEST=${PKGDEST:-$startdir} instead of hardcoding defaults PKGDEST=$startdir Jürgen
On 1/22/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
PKGDEST=${PKGDEST:-$startdir}
instead of hardcoding defaults
PKGDEST=$startdir
I like this solution. It fits with what jason was saying about regen'ing a repo too... export PKGDEST=/foo cd blah && makepkg cd blah && makepkg cd blah && makepkg ... they all go to /foo
On 1/22/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
PKGDEST=${PKGDEST:-$startdir}
instead of hardcoding defaults
PKGDEST=$startdir
I like this solution. It fits with what jason was saying about regen'ing a repo too... export PKGDEST=/foo cd blah && makepkg cd blah && makepkg cd blah && makepkg ... they all go to /foo
This works really well. Where the heck is this magic :- operator documented? -Dan
On 1/22/07, Dan McGee <dpmcgee@gmail.com> wrote:
This works really well. Where the heck is this magic :- operator documented?
Good question.... it might be in the Advanced Bash Scripting guide somewhere... though I didn't see a title that fit just now... aha "man bash" under "parameter expansion"
On Mon, Jan 22, 2007 at 04:45:51PM -0500, Dan McGee wrote:
On 1/22/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
PKGDEST=${PKGDEST:-$startdir}
instead of hardcoding defaults
PKGDEST=$startdir
I like this solution. It fits with what jason was saying about regen'ing a repo too... export PKGDEST=/foo cd blah && makepkg cd blah && makepkg cd blah && makepkg ... they all go to /foo
This works really well. Where the heck is this magic :- operator documented?
This is not bash specific: POSIX parameter expansion. Jürgen
This is not bash specific: POSIX parameter expansion.
Mind expanding on the POSIX parameter expander? :P (word play for the win!) ~ Jamie / yankees26
*groan*
Whats wrong with a good ol' pun? But due to vmlikos' link...I shall explain. In our case, if PKGDEST is unset, make it the same as $startdir, otherwise keep it the way it is. ~ Jamie / yankees26
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
*groan*
Whats wrong with a good ol' pun?
But due to vmlikos' link...I shall explain.
In our case, if PKGDEST is unset, make it the same as $startdir, otherwise keep it the way it is.
If you want to patch makepkg to use this, that would be great. The SRCDEST variable should be treated the same way now too.
If you want to patch makepkg to use this, that would be great. The SRCDEST variable should be treated the same way now too.
Tada (below). ~ Jamie / yankees26 Signed-off-by: James Rosten <seinfeld90@gmail.com> --- pacman-lib.orig/scripts/makepkg 2007-01-22 16:44:05.000000000 -0500 +++ pacman-lib/scripts/makepkg 2007-01-22 17:38:34.000000000 -0500 @@ -27,7 +27,7 @@ myver='3.0.0' startdir=$(pwd) -PKGDEST=$startdir +PKGDEST=${PKGDEST:-$startdir} BUILDSCRIPT="PKGBUILD" PKGEXT="pkg.tar.gz" @@ -327,6 +327,8 @@ if [ -f ~/.makepkg.conf ]; then source ~/.makepkg.conf fi +SRCDEST=${SRCDEST:-"/var/cache/pacman/src"} + while [ "$#" -ne "0" ]; do case $1 in # pacman
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
Signed-off-by: James Rosten <seinfeld90@gmail.com>
--- pacman-lib.orig/scripts/makepkg 2007-01-22 16:44:05.000000000 -0500 +++ pacman-lib/scripts/makepkg 2007-01-22 17:38:34.000000000 -0500 @@ -27,7 +27,7 @@
myver='3.0.0' startdir=$(pwd) -PKGDEST=$startdir +PKGDEST=${PKGDEST:-$startdir}
BUILDSCRIPT="PKGBUILD" PKGEXT="pkg.tar.gz" @@ -327,6 +327,8 @@ if [ -f ~/.makepkg.conf ]; then source ~/.makepkg.conf fi
+SRCDEST=${SRCDEST:-"/var/cache/pacman/src"} + while [ "$#" -ne "0" ]; do case $1 in # pacman
I was thinking about this, and there's a little problem. PKGDEST and SRCDEST can be set by makepkg.conf and ~/.makepkg.conf, overriding the envvar, which, I'd assume, should take precedence. The shortest solution is to rename either the makepkg.conf variable or the makepkg one... Basically, I foresee it working like so, in order of precedence: 1) environment settings or 2) ~/.makepkg.conf settings or 3) /etc/makepkg.conf settings
I was thinking about this, and there's a little problem. PKGDEST and SRCDEST can be set by makepkg.conf and ~/.makepkg.conf, overriding the envvar, which, I'd assume, should take precedence.
The shortest solution is to rename either the makepkg.conf variable or the makepkg one... Basically, I foresee it working like so, in order of precedence:
1) environment settings or 2) ~/.makepkg.conf settings or 3) /etc/makepkg.conf settings
In that case we preserve the environment's PKGDEST and SRCDEST in underscored versions, _PKGDEST and _SRCDEST. Then source the makepkg.conf and if the underscored versions are empty then we just fill PKGDEST and SRCDEST with makepkg.conf's ones using the :- spiel. Patch is below. ~ Jamie / yankees26 Signed-off-by: James Rosten <seinfeld90@gmail.com> --- pacman-lib.orig/scripts/makepkg 2007-01-22 16:44:05.000000000 -0500 +++ pacman-lib/scripts/makepkg 2007-01-22 18:47:38.000000000 -0500 @@ -27,7 +27,6 @@ myver='3.0.0' startdir=$(pwd) -PKGDEST=$startdir BUILDSCRIPT="PKGBUILD" PKGEXT="pkg.tar.gz" @@ -314,6 +313,8 @@ usage() { ARGLIST=$@ +_PKGDEST=$PKGDEST +_SRCDEST=$SRCDEST #Source makepkg.conf; fail if it is not found if [ -f /etc/makepkg.conf ]; then source /etc/makepkg.conf @@ -327,6 +328,9 @@ if [ -f ~/.makepkg.conf ]; then source ~/.makepkg.conf fi +PKGDEST=${_PKGDEST:-$PKGDEST} +SRCDEST=${_SRCDEST:-$SRCDEST} + while [ "$#" -ne "0" ]; do case $1 in # pacman
Status on this? Seems like a good solution to me. -Dan On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
In that case we preserve the environment's PKGDEST and SRCDEST in underscored versions, _PKGDEST and _SRCDEST. Then source the makepkg.conf and if the underscored versions are empty then we just fill PKGDEST and SRCDEST with makepkg.conf's ones using the :- spiel.
Patch is below.
~ Jamie / yankees26
Signed-off-by: James Rosten <seinfeld90@gmail.com> --- pacman-lib.orig/scripts/makepkg 2007-01-22 16:44:05.000000000 -0500 +++ pacman-lib/scripts/makepkg 2007-01-22 18:47:38.000000000 -0500 @@ -27,7 +27,6 @@
myver='3.0.0' startdir=$(pwd) -PKGDEST=$startdir
BUILDSCRIPT="PKGBUILD" PKGEXT="pkg.tar.gz" @@ -314,6 +313,8 @@ usage() {
ARGLIST=$@
+_PKGDEST=$PKGDEST +_SRCDEST=$SRCDEST #Source makepkg.conf; fail if it is not found if [ -f /etc/makepkg.conf ]; then source /etc/makepkg.conf @@ -327,6 +328,9 @@ if [ -f ~/.makepkg.conf ]; then source ~/.makepkg.conf fi
+PKGDEST=${_PKGDEST:-$PKGDEST} +SRCDEST=${_SRCDEST:-$SRCDEST} + while [ "$#" -ne "0" ]; do case $1 in # pacman
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On Mon, Jan 22, 2007 at 04:45:51PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
This works really well. Where the heck is this magic :- operator documented?
http://www.gnu.org/software/bash/manual/bashref.html#SEC29 as always, in the fine manual udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
participants (7)
-
Aaron Griffin
-
Dan McGee
-
James Rosten
-
Jason Chu
-
Jürgen Hötzel
-
Scott Horowitz
-
VMiklos