Re: port installation basics

On Thu, Sep 12, 2024 at 12:41:02PM GMT, Edward Sanford Sutton, III wrote:

> > I am torn between packages and ports. I read discouraging things
> > about using both, and yet I seem to need both for the following
> > reasons:

> Using both has problems if you change an option which changes what
> is available from a dependency; if you change something in a custom
> built dependency then you "may" need to custom build what depends on
> it too.  Making other changes like switching compilers completely
> might create problematic scenarios too requiring what depends on it
> to be built manually.  Another issue can arise when you build ports
> from a tree that is a different git checkout from the one used in
> official packages. Even more confusing to think about when realizing
> that not every package is rebuilt with every update; different
> packages therefore don't always come from the same tree state even
> on the official repo.

Another thing I seem to remember from my previous dabblings (long
ago): if I install a package (say bash) and later I build a port that
has bash as a dependency, it will be rebuilt (and maybe even
reinstalled, I don't remember that part anymore). I'd say this is
broken, but maybe it's different now?

> > I have not figured out how to build ports without getting sucked
> > into unbounded rabbit holes of configuration dialogs. I know the
> > advice to do `make config-recursive` upfront, but it doesn't help:
> > what seems to be happening is that I get config dialogs for *all
> > potential* recursive dependencies of the port I'm building,
> > regardless of my answers along the way. For example, even if I
> > exclude X11 support in git configuration, I am then confronted
> > with dialogs which are only relevant to gitk. Is there any way to
> > avoid this?

I've tried this multiple times, always building a list of overrides
in make.conf (mostly negative ones). I always end up in such a rabbit
hole. I don't know what I'm doing wrong :(

One of the things I like about FreeBSD is that pretty much everything
has a manpage. That used to be true in some penguin distros as well,
but not any more. So I try to turn on an option for that, if there is
one.

> `make -DBATCH` will build with defaults while `make -DINTERACTIVE`
> works for the remaining ports and skips batchable ports. Most
> support batch anyway. You can also define these in /etc/make.conf by
> adding lines like BATCH=yes.

This is interesting and potentially helpful. If I run `make -DBATCH`
in a particular port subtree, will this also be in effect for the
dependencies?

> Flavors were the answer to get ports that can be packaged with
> different options or dependencies. I say it needs work to reach full
> potential but its a start and can cover cases like with/without a
> gui or building to depend on different version of interpreters.

Are flavors visible in the pkg tool in any way other than as simply
separate packages (like emacs and emacs-nox)?

> Similarly, if you are building+installing directly from the ports
> tree, you are building in an unclean environment (at least after the
> first port).  Sometimes the ported program uses a build system that
> dynamically detects the environment and modifies the build according
> to what it sees. If the port doesn't override autodetections with
> guaranteed forced states of what should be available or not then you
> get a package that depends on something that isn't tracked properly

I don't quite get this. Where else would the "impostor" environment
come from? Things like a custom PATH you mean? I never got far enough
for that to be a problem :-P

-- 
Ian