FS#59126 - [pacman] [makepkg] ${pkgdir} not consistent if PKGBUILD is inside a symlinked directory

Attached to Project: Pacman
Opened by AMM (amish) - Sunday, 24 June 2018, 09:01 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 17 July 2018, 23:43 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.0
Due in Version 5.1.1
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
I am noticing this issue after pacman version 5.1.0 because I did not come across this issue earlier.

makepkg does not seem to generate consistent ${pkgdir} when it is run inside a symlinked directory.

Lets say there is a directory /home/john.
Lets say there is also a symlink /shared/john -> /home/john

Now lets create a minimal PKGBUILD under /home/john/AUR/foo.

It does nothing but just echoes the ${pkgdir}

pkgname=foo
pkgver=1.0
pkgrel=1
arch=('x86_64')

package() {
echo LOG: foo: ${pkgdir}
}

Now lets try to create the package:
$ cd /home/john/AUR/foo
$ makepkg
...
==> Starting package()...
LOG: foo: /home/john/AUR/foo/pkg/foo
...

So in this case pkgdir is as expected i.e. /home/john/AUR/foo/pkg/foo

Now lets do the same from symlinked directory:
$ cd /shared/john/AUR/foo
$ rm -rf pkg src foo-1.0-1-x86_64.pkg.tar.xz
$ makepkg
...
==> Starting package()...
LOG: foo: /home/john/AUR/foo/foo/pkg/foo
...


Notice that pkgdir has additional directory "foo" under /home/john/AUR/foo.

The expected output was either:
/home/john/AUR/foo/pkg/foo
OR
/shared/john/AUR/foo/pkg/foo

So somewhere this directory creation is inconsistent.

This creates issue in one of my script (post makepkg script) which expects binary/data files under /shared/john/AUR/foo/pkg/foo.

I have already created a workaround for my issue but reporting this as a makepkg (pacman) bug as it should create consistent pkgdir directory.

Additional info:
* package version(s)
Since pacman 5.1.0

* config and/or log files etc.
None

Steps to reproduce:
See Description above.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Tuesday, 17 July 2018, 23:43 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#58865 
Comment by Allan McRae (Allan) - Sunday, 24 June 2018, 12:17 GMT
Fairly sure we have fixed this in git.
Comment by AMM (amish) - Sunday, 24 June 2018, 12:52 GMT

Loading...