[pacman-dev] [PATCH] Change directory in package function in PKGBUILD.proto
makepkg goes back to the $startdir between the build() and package() functions so we need to change directory at the start of the package function. TODO: fix makepkg to make this unnecessary Signed-off-by: Allan McRae <allan@archlinux.org> --- PKGBUILD.proto | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/PKGBUILD.proto b/PKGBUILD.proto index 0134574..b4d9c94 100644 --- a/PKGBUILD.proto +++ b/PKGBUILD.proto @@ -34,6 +34,8 @@ build() { } package() { + cd "$srcdir/$pkgname-$pkgver" + make DESTDIR="$pkgdir/" install } -- 1.7.1
On Wed, May 19, 2010 at 10:32:54PM +1000, Allan McRae wrote:
makepkg goes back to the $startdir between the build() and package() functions so we need to change directory at the start of the package function.
TODO: fix makepkg to make this unnecessary
Although annoying at the beginning , The current behaviour is straight-forward and makes sense. Especially in the case where multiple package functions cd to different dirs. You can do this when no package splitting is used, but that will make makepkg's behaviour unpredictable.
On 19/05/10 23:51, Nezmer wrote:
On Wed, May 19, 2010 at 10:32:54PM +1000, Allan McRae wrote:
makepkg goes back to the $startdir between the build() and package() functions so we need to change directory at the start of the package function.
TODO: fix makepkg to make this unnecessary
Although annoying at the beginning , The current behaviour is straight-forward and makes sense. Especially in the case where multiple package functions cd to different dirs.
You can do this when no package splitting is used, but that will make makepkg's behaviour unpredictable.
I was thinking it should keep the current directory when it moves between any functions (build or package{_foo}). You can always cd the full path not if that is not what you want for a particular package. The vast majority of "cd" commands at the start of PKGBUILD functions go to the one directory so this makes sense to me as long as it can be overridden. Anyway... no point discussing a potential future feature that does not have a patch :P
participants (2)
-
Allan McRae
-
Nezmer