On Thu, May 09, 2019 at 10:22:48PM +0200, Charlène Wendling wrote:
> make update-plist
> =================
>
> => doas /usr/bin/perl /usr/ports/infrastructure/bin/update-plist
>
> In mk/pkgpath.mk there is this:
>
> _PERLSCRIPT = /usr/bin/perl ${PORTSDIR}/infrastructure/bin
>
> After removing the perl invocation the problem is getting fishier:
>
> - /usr/ports/infrastructure/bin/update-plist is executable, fine
> - /usr/ports/infrastructure/bin/port-getpkgpath-helper is not
> executable, i chmoded +x it to see how deep it goes
> - then it calls 'doas /usr/ports/infrastructure/bin/update-plist'
> - and it croaks:
Those are a problem, because you can't really enforce +x under source
directories. Removing the _PERLSCRIPT everywhere is a bad idea.
(note that src suffers from the same issue and explicitly prefix with
/bin/sh every script it's going to run).
The only script that really wants root is update-plist. Entering a
password for that one looks admissible.
> make clean=packages
> ===================
>
> - my user account wants to rm:
> /usr/ports/packages/amd64/cache/portname.tgz
> and it belongs to _pfetch, so i needed this in bsd.port.mk:
>
> @@ -3120,10 +3120,10 @@ _internal-clean:
> .endif
> .if ${_clean:Mpackages} || ${_clean:Mpackage} && ${_clean:Msub}
> ${_PBUILD} rm -f ${_PACKAGE_COOKIES}
> - rm -f ${_UPDATE_COOKIES} ${_CACHE_PACKAGE_COOKIES}
> + ${_PFETCH} rm -f ${_UPDATE_COOKIES} ${_CACHE_PACKAGE_COOKIES}
> .elif ${_clean:Mpackage}
> ${_PBUILD} rm -f ${_PACKAGE_COOKIES${SUBPACKAGE}}
> - rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
> + ${_PFETCH} rm -f ${_UPDATE_COOKIE${SUBPACKAGE}}
Err, this is weird. ${_CACHE_PACKAGE_COOKIES} will indeed belong to _pfetch.
Not so for ${_UPDATE_COOKIES}
