On Thu, 9 May 2019 22:35:10 +0200
Marc Espie <[email protected]> wrote:
> 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.
I agree, as you propose it, i think it's already nice enough, this
reduces massively the count of password prompts with PORT_PRIVSEP
and "permit keepenv $USER", and anyway if you set doas as this,
you know you're gonna type your password often.
> > 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}
>
It was a wild guess, after the mess i did to get up to this point, i
understood that there was no future for this, and cut to the chase.
