[pacman-dev] pacman 5.1.1 and the "final" makepkg bug

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20180621/12c82efe/attachment.asc>