On 06/20/2018 09:41 PM, Allan McRae wrote:
Hi all,
I think we are near the point for a pacman-5.1.1 release. My intention is for it to be basically what on master current + the couple of patches in my patchqueue branch.
The final thing that needs addressing is: https://bugs.archlinux.org/task/58776
The gist of this bug is makepkg --printsrcinfo was giving entries like "depends = perl>=". We caught these entries because they could be a genuine mistake. It turns out this also happens when the version used requires some bash that calls a function or variable that is not at a global scope.
While this is fairly easily worked around, it breaks all perl PKGBUILDs that use the makepkg-template in Arch Linux, and removes the "anything correct bash is OK" mantra of PKGBUILDs.
I see some choices here:
1) back out the change 2) partially back out the change 3) "hide" the change 4) document the change
For 2), I could see changing the error to a warning, documenting the change and including it for next release.
For 3), we could print a warning, then strip these empty "<=" at the end. Note libprovides and libdepends have dynamcially generated versions that are not in --sourceinfo so this would align with them. We should document that limitation.
Opinions? (I'm leaning towards #3)
libprovides/libdepends are only sort of similar. They're the ideal state of what the perl template really should be. :p I dislike option 1, because it results in broken .SRCINFO at the very least and depending on implementation will result in genuinely allowing bad PKGBUILDs to pass linting. option 2 I see no real point in. If we consider these PKGBUILDs to be broken, then giving people extra time to fix them may be nice but it's also hardly makepkg's problem. option 3 is an interesting proposition, but where should we do this? We cannot modify function variables in the lint stage. We could hack something into otherwise unrelated code in write_srcinfo and write_pkginfo, though, slightly repetitively. In all honesty, I'd much prefer to just explicitly document that "metadata in split package functions cannot be multi-statement bash, but otherwise anything bash goes". This is not the only issue with extracting metadata from the package function, e.g. https://bugs.archlinux.org/task/55004 And sure, as soon as the internal context of the function is run, we suddenly get the intended behavior asserted. But up until then, it just doesn't work. It caused issues for printsrcinfo, and now that we're trying to do better linting it's causing issues for that too. -- Eli Schwartz Bug Wrangler and Trusted User