how is it detecting how much memory to use? if it's looking at available
physical memory without considering resource limits, could that be changed?

there is precedent for programs to adjust RLIMIT_DATA from the default to
the max available within the current limit if they know they're likely
to need it - see e.g. src/usr.bin/sort/sort.c.

if it's possible to automate this within reasonable bounds, this would
be better than asking the user to adjust login.conf themselves.


On 2022/05/20 19:35, Omar Polo wrote:
> Hello Rubén,
> 
> Rubén Llorente <port...@use.startmail.com> wrote:
> > Port for lrzip included as an attachment.
> > 
> > 
> > On Wed, May 18, 2022 at 12:49:51AM +0100, Stuart Henderson wrote:
> > > please send ports as attachments to the list
> > > 
> 
> Some comments on the port:
> 
> - COMMENT should start with a lowercase.  (maybe we can also shorten it
>   to 'compression utility for large files'?)
> 
> - no need fo $V if it's used only in one place
> 
> - upstream seems to have moved to github and has release other versions
>   (the latest one being 0.651.)  Other popular package repositories are
>   using that version, so I think we should follow.  patch-lrzip_private_h
>   needs to be regen'd.  Using the autogenerated tarball from github
>   means that we need to run autoreconf & friends too.
> 
> - SEPARATE_BUILD fails with latest version, so drop it
> 
> - shuffle a bit to be in order with Makefile.template
> 
> - targets are indented with a single tab
> 
> - drop NO_TEST: it's used only when `make test' fails because there
>   isn't a regress suite.  Here there isn't a regress suite but `make
>   test' doesn't fails.  Avoiding to set NO_TEST helps when upstream then
>   adds one. 
> 
> - pkg/SECURITY it a new one for me.  portcheck complains that's an extra
>   file.  If the content is important, maybe add some comments in the
>   Makefile, but I'd drop it.
> 
> - pkg/PLIST needed a regen.  are you by any chance not using -current?
>   ports development should be done in -current.  (asking because your
>   plist lacked a @static-lib marker, it's been there for a few years at
>   least...)
> 
> - similarly, I'd drop pkg/MESSAGE.  There's a little point in having two
>   files with the same content (pkg/MESSAGE and README), and READMEs are
>   handier.
> 
> - nitpick: I'd reformat the DESCR at 72 chars, it reads better IMHO.
> 
> - regarding the readme:
> 
> : Suggested values follow:
> : 
> :         :datasize-cur=4096: \
> :         :datasize-max=infinity: \
> :         :stacksizemax=80M:
> 
>   hummmmm...  `infinity' it's hardly a "suggested" value.  also,
>   stacksizemax?  maybe just point out that this is a memory-hungry port
>   and that the default values may not be enough?
> 
> 
> The good news is that with the above changes the ports looks good IMHO.
> The bad news is that now the builds fails (link error in the embedded
> lzma copy) so it needs more work (using lzma from ports if possible)
> 
> I'm attaching a tarball with above suggestions included.
> 
> Cheers,
> 
> Omar Polo
> 


Reply via email to