Rhialto <rhialto%falu.nl@localhost> writes:
> On Sun 24 Jan 2021 at 19:35:17 -0900, Michael Huff wrote:
>> Thank you for the insight. For now, I was able to work around it by telling
>> the different ULIMIT_CMD entries in mk/platform/Linux.mk to use
>> /usr/bin/ulimit.
>
> What use is an external command /usr/bin/ulimit? (Yes, I see one on my
> Mac from $WORK: it contains builtin `echo ${0##*/} | tr \[:upper:]
> \[:lower:]` ${1+"$@"})
>
> Because ulimit is supposed to change the limits for the current process,
> running it in a separate process (which happens for non-builtin shell
> commands) has no effect at all on the current proces...
> It's just like an external /bin/cd command...
>
> So I wonder why that file even exists.
Reading the POSIX page again, it says exactly that.
The hard thing to figure out here is what flags pkgsrc expects ulimit to
support, whether this flag is one of them, and what to do about shells
that don't support the chosen set.
The easier thing is to understand where this is coming from in libcups,
and patch it out or deal with it. If libcups upstream is using a
ulimit flag not even specfied by the upcoming POSIX spec, that feels
like a bug, certainly if the build fails because of it. If libcups
documents that it needs some particular shell to build, pkgsrc needs to
arrange for it, even if it's a design bug in a package to not work with
any reasonable POSIX shell.
Attachment:
signature.asc
Description: PGP signature