Re: building print/libcups, cannot set ulimit on centos stream

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 25 Jan 2021 08:54:26 -0500
    From:        Greg Troxel <gdt%lexort.com@localhost>
    Message-ID:  <rmipn1tf7fx.fsf%s1.lexort.com@localhost>

  | 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.

I'm not sure why -m wasn't included in the new set of POSIX options, perhaps
some systems don't support the underlying limit - but this is (I think)
the only common option (ie: all shells try to support it and give it the
same meaning) that wasn't included.

So, I wouldn't worry too much about it.  Unless there is a need to build
on a system where -m doesn't work, there is no common shell that I know
of that doesn't support it (at least on NetBSD, and I'd assume on most
supported target systems).

kre

FWIW, POSIX is adding -H -S and -a (as generic options, not tied to specific
limits) and -c -d -n -s -t and -v (to -f which is the one which has long
existed) as options for specific limits.    Aside from -m, the other
limits which exist tend to be either not supported, or named or processed
differently, on different shells.   Eg: -p (pipe size) is not supported
by bosh, yash or zsh, and counts multiples of 512 in bash, rather than
simply bytes everywhere else it is supported.   Our -r (threads) is -T
in bash zsh and ksh93 (and not existing in many other shells).