On 2026/06/05 11:57, furyinbox@gmail.com wrote:
> 
> > While maybe the manuals could give more of a clue about where to find
> > these scripts, this doesn't seem a good way to do it, it still doesn't
> > say where to find them, and surely it's self evident that you need the
> > ports tree to be able to build the ports tree?
> 
> I did have ports tree at the time when I faced this problem but I
> couldn't infer from reading proot(1) that this tool is in inside of
> the ports tree.

I don't see how a comment saying that "you can't use X unless you have
the ports tree" implies that X is itself inside the ports tree though.

Adding something along the lines of "This tool can be found in the
infrastructure/bin directory of the ports tree" would seem reasonable
to me.

> I agree that it may be much better to mention path to the proot binary
> but I'm also afraid to introduce this new place of connection between
> this man page and file structure of the ports tree.
> Although maybe mentioning it in ports README file would be nice.
> It already mentions proot and dpb but again, even though I opened this
> README file I still couldn't infer that these tools are somewhere inside
> of the "infrastructure/bin" folder of ports tree.
> 
> Also looking at the ports tree for the first time I can pretty confidently
> guess that every folder is a category of programs so seeing
> "infrastructure" folder there I think of infrastructure management
> software (although I admit it can be learned behavior).
> I would've never thought it's about ports infrastructure, which I think
> is good to mention in ports main README file.

other special-purpose subdirs (some of which can be overridden by
mk.conf variables):

bulk
distfiles (or DISTDIR)
locks
logs (used by dpb)
mystuff
packages (or PACKAGE_REPOSITORY)
plist (or PLIST_REPOSITORY)
pobj (or WRKOBJDIR)
update

> > if you need to build in a chroot jail
> 
> Yup, that's exactly what I'm trying to do. Just want to make sure I
> don't pollute my system with build dependencies when I run "make".

opinions will differ, but personally I'd only ever use proot
specifically for running dpb on a box that is not dedicated as a bulk
build box. and I don't actually do that because I find it easier to spin
up a vm, so I don't actually use proot. instead I use pkg_delete -a to
keep on top of removing build dependencies.

> I've spent some more time looking at the man pages and I see that
> proot(1) mentions bsd.port.mk(5) which does in turn mention
> infrastructure folder:
> 
> > bsd.port.mk also uses quite a few helper scripts which live under
> > ${PORTSDIR}/infrastructure/bin.
> 
> Maybe I should spend time reading man pages more carefully. I think my
> context on ports and how the build process work in OpenBSD is too mixed
> up with FreeBSD and NetBSD as well as some Linux distros (the ones that
> have some form of ports tree).
> I'm happy to continue the discussion, maybe there is something to
> improve but I agree on the fact that the change I proposed isn't great.

Since there is no clue in dpb(1) or proot(1) about where to find the
tools, I think there is something to improve.

> P.S.
> I'm reading this list in marc.info and have no way to reply to messages
> so I'm going to decode message-id from marc.info and try to compose new
> email with "In-Reply-To" header. I hope it will come through correctly.
> Apologies if it doesn't.

yes that worked :)