[pacman-dev] [PATCH 2/2] Save path to Pacman, which could be lost during --syncdeps operation
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/: PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install --- scripts/makepkg.sh.in | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 3b4f27f..2b224b8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -873,9 +873,9 @@ source_has_signatures() { run_pacman() { local cmd if [[ ! $1 = -@(T|Qq) ]]; then - cmd=($PACMAN $PACMAN_OPTS "$@") + cmd=("${PACMAN[@]}" $PACMAN_OPTS "$@") else - cmd=($PACMAN "$@") + cmd=("${PACMAN[@]}" "$@") fi if (( ! ASROOT )) && [[ ! $1 = -@(T|Qq) ]]; then if type -p sudo >/dev/null; then @@ -898,7 +898,7 @@ check_deps() { if (( ret == 127 )); then #unresolved deps printf "%s\n" "$pmout" elif (( ret )); then - error "$(gettext "'%s' returned a fatal error (%i): %s")" "$PACMAN" "$ret" "$pmout" + error "$(gettext "'%s' returned a fatal error (%i): %s")" "${PACMAN[*]}" "$ret" "$pmout" return "$ret" fi } @@ -920,7 +920,7 @@ handle_deps() { msg "$(gettext "Installing missing dependencies...")" if ! run_pacman -S --asdeps $deplist; then - error "$(gettext "'%s' failed to install missing dependencies.")" "$PACMAN" + error "$(gettext "'%s' failed to install missing dependencies.")" "${PACMAN[*]}" exit 1 # TODO: error code fi fi @@ -1899,9 +1899,9 @@ install_package() { (( ! INSTALL )) && return if (( ! SPLITPKG )); then - msg "$(gettext "Installing package %s with %s...")" "$pkgname" "$PACMAN -U" + msg "$(gettext "Installing package %s with %s...")" "$pkgname" "${PACMAN[*]} -U" else - msg "$(gettext "Installing %s package group with %s...")" "$pkgbase" "$PACMAN -U" + msg "$(gettext "Installing %s package group with %s...")" "$pkgbase" "${PACMAN[*]} -U" fi local fullver pkgarch pkg pkglist @@ -2457,8 +2457,9 @@ if [[ $MAKEPKG_CONF = "$confdir/makepkg.conf" && -r ~/.makepkg.conf ]]; then source_safe ~/.makepkg.conf fi -# set pacman command if not already defined -PACMAN=${PACMAN:-pacman} +# Set pacman command if not already defined. Convert to Bash array so that +# spaces can be included in the path while any arguments are retained. +PACMAN=(${PACMAN:-pacman}) # check if messages are to be printed using color unset ALL_OFF BOLD BLUE GREEN RED YELLOW @@ -2728,7 +2729,11 @@ if (( NODEPS || (NOBUILD && !DEP_BIN ) )); then if (( NODEPS )); then warning "$(gettext "Skipping dependency checks.")" fi -elif type -p "${PACMAN%% *}" >/dev/null; then +elif output="$(command -v "$PACMAN")"; then + # Save full path to Pacman in case the --syncdeps operation modifies + # the $PATH and makes it inaccessible + PACMAN="$output" + if (( RMDEPS && ! INSTALL )); then original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi @@ -2757,7 +2762,7 @@ elif type -p "${PACMAN%% *}" >/dev/null; then exit 1 fi else - warning "$(gettext "%s was not found in %s; skipping dependency checks.")" "${PACMAN%% *}" "PATH" + warning "$(gettext "%s was not found in %s; skipping dependency checks.")" "$PACMAN" "PATH" fi # ensure we have a sane umask set -- 1.7.12
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
--- scripts/makepkg.sh.in | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 3b4f27f..2b224b8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -873,9 +873,9 @@ source_has_signatures() { run_pacman() { local cmd if [[ ! $1 = -@(T|Qq) ]]; then - cmd=($PACMAN $PACMAN_OPTS "$@") + cmd=("${PACMAN[@]}" $PACMAN_OPTS "$@") else - cmd=($PACMAN "$@") + cmd=("${PACMAN[@]}" "$@") fi if (( ! ASROOT )) && [[ ! $1 = -@(T|Qq) ]]; then if type -p sudo >/dev/null; then @@ -898,7 +898,7 @@ check_deps() { if (( ret == 127 )); then #unresolved deps printf "%s\n" "$pmout" elif (( ret )); then - error "$(gettext "'%s' returned a fatal error (%i): %s")" "$PACMAN" "$ret" "$pmout" + error "$(gettext "'%s' returned a fatal error (%i): %s")" "${PACMAN[*]}" "$ret" "$pmout" return "$ret" fi } @@ -920,7 +920,7 @@ handle_deps() { msg "$(gettext "Installing missing dependencies...")"
if ! run_pacman -S --asdeps $deplist; then - error "$(gettext "'%s' failed to install missing dependencies.")" "$PACMAN" + error "$(gettext "'%s' failed to install missing dependencies.")" "${PACMAN[*]}" exit 1 # TODO: error code fi fi @@ -1899,9 +1899,9 @@ install_package() { (( ! INSTALL )) && return
if (( ! SPLITPKG )); then - msg "$(gettext "Installing package %s with %s...")" "$pkgname" "$PACMAN -U" + msg "$(gettext "Installing package %s with %s...")" "$pkgname" "${PACMAN[*]} -U" else - msg "$(gettext "Installing %s package group with %s...")" "$pkgbase" "$PACMAN -U" + msg "$(gettext "Installing %s package group with %s...")" "$pkgbase" "${PACMAN[*]} -U" fi
local fullver pkgarch pkg pkglist @@ -2457,8 +2457,9 @@ if [[ $MAKEPKG_CONF = "$confdir/makepkg.conf" && -r ~/.makepkg.conf ]]; then source_safe ~/.makepkg.conf fi
-# set pacman command if not already defined -PACMAN=${PACMAN:-pacman} +# Set pacman command if not already defined. Convert to Bash array so that +# spaces can be included in the path while any arguments are retained. +PACMAN=(${PACMAN:-pacman})
# check if messages are to be printed using color unset ALL_OFF BOLD BLUE GREEN RED YELLOW @@ -2728,7 +2729,11 @@ if (( NODEPS || (NOBUILD && !DEP_BIN ) )); then if (( NODEPS )); then warning "$(gettext "Skipping dependency checks.")" fi -elif type -p "${PACMAN%% *}" >/dev/null; then +elif output="$(command -v "$PACMAN")"; then + # Save full path to Pacman in case the --syncdeps operation modifies + # the $PATH and makes it inaccessible + PACMAN="$output" + if (( RMDEPS && ! INSTALL )); then original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi @@ -2757,7 +2762,7 @@ elif type -p "${PACMAN%% *}" >/dev/null; then exit 1 fi else - warning "$(gettext "%s was not found in %s; skipping dependency checks.")" "${PACMAN%% *}" "PATH" + warning "$(gettext "%s was not found in %s; skipping dependency checks.")" "$PACMAN" "PATH" fi
# ensure we have a sane umask set -- 1.7.12
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
@@ -2728,7 +2729,11 @@ if (( NODEPS || (NOBUILD && !DEP_BIN ) )); then if (( NODEPS )); then warning "$(gettext "Skipping dependency checks.")" fi -elif type -p "${PACMAN%% *}" >/dev/null; then +elif output="$(command -v "$PACMAN")"; then + # Save full path to Pacman in case the --syncdeps operation modifies + # the $PATH and makes it inaccessible + PACMAN="$output" + if (( RMDEPS && ! INSTALL )); then original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi
On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote:
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
Right. PACMAN defines a command, not a command and options. I'm a little confused as to why this would be needed. Presumably, pacman is in /usr/bin. If that falls out of your PATH, you're going to have much larger problems, and it won't only be pacman which is no longer accessible. Could you perhaps expand on your use case and why/how you ran into this problem?
@@ -2728,7 +2729,11 @@ if (( NODEPS || (NOBUILD && !DEP_BIN ) )); then if (( NODEPS )); then warning "$(gettext "Skipping dependency checks.")" fi -elif type -p "${PACMAN%% *}" >/dev/null; then +elif output="$(command -v "$PACMAN")"; then + # Save full path to Pacman in case the --syncdeps operation modifies + # the $PATH and makes it inaccessible + PACMAN="$output" + if (( RMDEPS && ! INSTALL )); then original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi
On 3 November 2012 04:25, Dave Reisner <d@falconindy.com> wrote:
On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote:
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
Right. PACMAN defines a command, not a command and options.
I'm a little confused as to why this would be needed. Presumably, pacman is in /usr/bin. If that falls out of your PATH, you're going to have much larger problems, and it won't only be pacman which is no longer accessible. Could you perhaps expand on your use case and why/how you ran into this problem?
Also mentioned my earlier thread (https://mailman.archlinux.org/pipermail/pacman-dev/2012-October/016021.html), but I shall expand here. I have a Pacman wrapper called “roopwn” that I am playing with, linked in my ~/bin/ directory. This seems to me to be a nice way to use it as I develop it. So my original problem was that if the --syncdeps operation gets run, I get some odd error messages, and the --install operation doesn’t automatically work: [vadmium@patig pacaur]$ PACMAN=roopwn /usr/bin/makepkg --syncdeps --install ==> Making package: pacaur 3.2.6-1 (Sat Nov 3 04:32:59 UTC 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... resolving dependencies... Packages (1): expac-1-1 Total Download Size: 0.00 MiB Proceed with download? [Y/n] (1/1) checking package integrity [######################] 100% analysing file dependencies... loading packages... resolving dependencies... looking for inter-conflicts... Packages (1): expac-1-1 Total Installed Size: 0.05 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [######################] 100% (1/1) loading package files [######################] 100% (1/1) checking for file conflicts [######################] 100% (1/1) checking available disk space [######################] 100% (1/1) installing expac [######################] 100% /usr/bin/makepkg: line 434: roopwn: command not found ==> Checking buildtime dependencies... /usr/bin/makepkg: line 434: roopwn: command not found ==> Retrieving Sources... -> Found pacaur-3.2.6.tar.gz ==> Validating source files with md5sums... pacaur-3.2.6.tar.gz ... Passed ==> Extracting Sources... -> Extracting pacaur-3.2.6.tar.gz with bsdtar ==> Removing existing pkg/ directory... ==> Entering fakeroot environment... ==> Starting build()... ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: pacaur 3.2.6-1 (Sat Nov 3 04:33:03 UTC 2012) ==> Installing package pacaur with roopwn -U... sudo: roopwn: command not found ==> WARNING: Failed to install built package(s). [vadmium@patig pacaur]$
@@ -2728,7 +2729,11 @@ if (( NODEPS || (NOBUILD && !DEP_BIN ) )); then if (( NODEPS )); then warning "$(gettext "Skipping dependency checks.")" fi -elif type -p "${PACMAN%% *}" >/dev/null; then +elif output="$(command -v "$PACMAN")"; then + # Save full path to Pacman in case the --syncdeps operation modifies + # the $PATH and makes it inaccessible + PACMAN="$output" + if (( RMDEPS && ! INSTALL )); then original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi
On 03/11/12 14:38, Martin Panter wrote:
On 3 November 2012 04:25, Dave Reisner <d@falconindy.com> wrote:
On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote:
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
Right. PACMAN defines a command, not a command and options.
I'm a little confused as to why this would be needed. Presumably, pacman is in /usr/bin. If that falls out of your PATH, you're going to have much larger problems, and it won't only be pacman which is no longer accessible. Could you perhaps expand on your use case and why/how you ran into this problem?
Also mentioned my earlier thread (https://mailman.archlinux.org/pipermail/pacman-dev/2012-October/016021.html), but I shall expand here.
I have a Pacman wrapper called “roopwn” that I am playing with, linked in my ~/bin/ directory. This seems to me to be a nice way to use it as I develop it.
So my original problem was that if the --syncdeps operation gets run, I get some odd error messages, and the --install operation doesn’t automatically work:
<snip> I still find it a bit strange to have a system package management app outside of the system PATH but I have no objections to supporting this. Of course, you could use "PACMAN=~/bin/roopwn". Anyway, I think we would be fine with the following to patches: 1) A patch that replaces the PACMAN value with the full path to avoid your issues. There is no need to support adding options to that command - in fact... don't - it should be just the command. 2) A patch that allows PACMAN_OPT to be used to pass options to the PACMAN command. @Dave: have I interpreted your opinions correctly? Allan
On Sat, Nov 03, 2012 at 02:55:07PM +1000, Allan McRae wrote:
On 03/11/12 14:38, Martin Panter wrote:
On 3 November 2012 04:25, Dave Reisner <d@falconindy.com> wrote:
On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote:
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
Right. PACMAN defines a command, not a command and options.
I'm a little confused as to why this would be needed. Presumably, pacman is in /usr/bin. If that falls out of your PATH, you're going to have much larger problems, and it won't only be pacman which is no longer accessible. Could you perhaps expand on your use case and why/how you ran into this problem?
Also mentioned my earlier thread (https://mailman.archlinux.org/pipermail/pacman-dev/2012-October/016021.html), but I shall expand here.
I have a Pacman wrapper called “roopwn” that I am playing with, linked in my ~/bin/ directory. This seems to me to be a nice way to use it as I develop it.
So my original problem was that if the --syncdeps operation gets run, I get some odd error messages, and the --install operation doesn’t automatically work:
<snip>
I still find it a bit strange to have a system package management app outside of the system PATH but I have no objections to supporting this. Of course, you could use "PACMAN=~/bin/roopwn".
Anyway, I think we would be fine with the following to patches:
1) A patch that replaces the PACMAN value with the full path to avoid your issues. There is no need to support adding options to that command - in fact... don't - it should be just the command.
2) A patch that allows PACMAN_OPT to be used to pass options to the PACMAN command.
@Dave: have I interpreted your opinions correctly?
Yup, spot on. d
participants (3)
-
Allan McRae
-
Dave Reisner
-
Martin Panter