Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.

FS#58776 - makepkg fails if dependency version is the result of evaluating a function

Attached to Project: Pacman
Opened by Antonio Rojas (arojas) - Tuesday, 29 May 2018, 13:31 GMT
Last edited by Allan McRae (Allan) - Friday, 27 July 2018, 01:00 GMT
Task Type Bug Report
Category makepkg
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 0
Private No


Summary and Info:
All binary perl packages on Arch use this snippet to set the perl version in depends:

if [[ $(find "$pkgdir/usr/lib/perl5/" -name "*.so") ]]; then
_perlver_min=$(perl -e '$v = $^V->{version}; print $v->[0].".".($v->[1]);')
_perlver_max=$(perl -e '$v = $^V->{version}; print $v->[0].".".($v->[1]+1);')
depends+=("perl>=$_perlver_min" "perl<$_perlver_max")

This fails with makepkg 5.1 with an error
==> ERROR: pkgver in depends is not allowed to be empty.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 27 July 2018, 01:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  The strictness of this check has been reduced. git commit 316b031b
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 13:39 GMT
I regard this as a feature, not a bug.

Try running makepkg --printsrcinfo, you'll see things like

pkgver = perl>=

The new linting checks for invalid dependency specifiers quite rightly dislike this, but they don't know how to run this complicated if statement, for the same reason as  FS#55004 

IMHO the versioned dependency should be dropped. Perl uses versioned libdirs now, anyway.
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 20:46 GMT
r8168 is affected too, it uses versioned kernel depends.
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 20:56 GMT
The simplest solution is probably to use something like

depends+=("perl${_perlver_min:+>=$_perlver_min}" "perl${_perlver_max:+<$_perlver_max}")
Comment by Allan McRae (Allan) - Tuesday, 29 May 2018, 21:52 GMT
That seems to be just hiding the issue.
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 22:15 GMT
Well, or inline it, depending on how large the cmdline is. The r8168 PKGBUILD uses:

depends=("linux>=$_kernver" "linux<${_kernver/.*}.$(expr ${_kernver/*.} + 1)")

Which... well, fallback values won't really work there, actually. It would need some global helper function (which will be eval'ed just fine)
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 May 2018, 23:45 GMT
perlver() { perl -e '$v = $^V->{version}; print $v->[0].".".($v->[1]+$ARGV[0]);' $1; }

if [[ $(find "$pkgdir/usr/lib/perl5/" -name "*.so") ]]; then
depends+=("perl>=$(perlver)" "perl<$(perlver 1)")

Should work fine, and the .SRCINFO it generates will actually contain the versioned specifier.
(It will also always claim to depend on versioned perl, which I guess is better than never.)

This assumes we don't want to just drop the versioned dependency entirely due to the existing versioned libdir and detect-old-perl-modules.hook which will loudly warn the user on *every* upgrade that modifies /usr/lib/perl5, if any perl modules are the wrong version.

We don't usually try to version our dependencies in the first place, and IIRC we did this by perl because of the infamous "your mismatched modules will crash the perl interpreter even if you don't try using those modules" thing, which is now fixed anyway due to
Comment by Sergej Pupykin (sergej) - Wednesday, 06 June 2018, 17:13 GMT
I think this is perl package bug because of /usr/share/makepkg-template/perl-binary-module-dependency.template belongs to perl.
Comment by Florian Pritz (bluewind) - Wednesday, 06 June 2018, 17:54 GMT
I wanted to wait for a final decision from Allan before doing anything here, but apparently people keep running into this. We don't need the template any more so feel free to remove it from affected packages.
Comment by Eli Schwartz (eschwartz) - Wednesday, 06 June 2018, 18:38 GMT
> That seems to be just hiding the issue.

Actually, thinking about this, this is more or less the same as libdepends/libprovides, which also evaluate the versioned component (in a much more complex fashion) only in the actual packaging stage but not when generating srcinfo. Whether it *should* be versioned is another question, of course.

And thinking about that, I think if people do want versioned dependencies this is better implemented as a libmakepkg drop-in.
Comment by Allan McRae (Allan) - Thursday, 21 June 2018, 01:43 GMT
To clarify this bug... The failure is only when using other variables or functions defined within the package() function. If these are defined at a global scope, all is fine.
Comment by Eli Schwartz (eschwartz) - Thursday, 21 June 2018, 04:36 GMT
There's other issues too, when trying to define metadata within package(), like  FS#55004