Re: port installation basics

On 9/12/24 11:25, fatty.merchandise677@aceecat.org wrote:
> Hello, I'm trying FreeBSD again (penguin news is depressing) and I
> face again some of the problems I remember.
> 
> 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.
   Keep in mind that all officially available packages were built form 
the ports tree and installing a custom built port installs it as a 
package on your system. You could always update official packages and 
then reinstall custom built ones as a second step. The repository they 
came from should be logged as part of the package install.
   A build system like poudriere keeps track of various changes and 
incompatibilities. It can delete packages when it looks like libraries 
it depends on have changed or if port options have changed.compared to 
what it was last built with.

> - there are a few things I absolutely must have on a system to do
>    anything at all (so in particular, to set up and compile ports):
>    bash, sudo, screen, vim, rsync, git. I think that covers it.
>    These are not in the base, so I must install packages for them.
>    This alone wouldn't be a show stopper because I could rebuild them
>    from ports once I'm up and running. But.

   Assuming you want to compile things yourself, I'd recommend git (or 
whatever alternative) be used to fetch the ports tree to be able to 
update it. You can start with a ports tree extracted from an archive 
found on some install media to build+install git or other tools if you 
don't want to use official packages. You can move/remove the tree once 
you have git or other tooling worked out to fetch+update the tree as 
appropriate.

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

   Been a while since I last looked but it doesn't include potential 
dependencies; the dependency list is walked based on actual dependencies 
which may alter further dialogs depending on answers to earlier dialogs. 
Maybe try to track down where that got included as a dependency with 
ports-mgmt/porttree . Did you define any overrides in /etc/make.conf 
that would have impacted port's options/dependencies?
   `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.
   Using a system like poudriere has the ability to define port build 
options but otherwise you get the defaults until you take the time to do so.

> - on the other hand, some packages are egregiously over-configured,
>    often with GUI extras I have no use for. For example, graphviz.  I
>    just want to run dot to build png or pdf files. So this would be a
>    good time to use a port (which I assume can disable the GUI parts),
>    if it weren't for the above.

   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.
   I'm of the stance that overconfigured is better than someone needing 
to run make to get what is missing is a good thing, though between 
things being rarely used, exploitable, and general bloat I do see value 
in not enabling all options being sane too. Good programs have build 
dependencies add a feature but runtime can detect what is available so 
it only needs to be built with many dependencies available and runtime 
dependencies are small but program expands as others are optionally 
installed with recompiling anything.
   If you are doing no GUI stuff then defining "OPTIONS_UNSET+=GUI X11 
WAYLAND" and similar in /etc/make.conf would turn off the options, 
otherwise you need different syntax or techniques to specify it per 
port. Some ports things moved over from options to flavors for some of 
this so you may find you need to request a flavor instead of set options 
to get what you want.

> Your thoughts?  Thanks,

   The easy and fast solution is using official packages. Options cannot 
be changed for them without building them manually, but different 
flavors can be built and hosted on official package repositories so you 
may find what you wanted available that way. Flavors still seem like an 
awkward thing in various tools; I normally don't think much about them 
as I use poudriere to do custom builds of everything (for me its a 
minimal need and done mostly because I can and its old working workflow).
   As a side note, the more you change, the more you may run into issues 
not observed by others or accounted for in the ports tree. This doesn't 
require mixing packages & ports or different tree versions. If you try 
hard enough then you learn that a port breaks by toggling a provided 
option/setting like NLS or docs. I've had ports break because of a bug 
with -O0 broke the program; maintainer and I agreed time was better 
spent updating the version than fixing such bug.
   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 and may 
even install files that are unaccounted for since the port had a 
different or no setting for the optional part and the pkg-plist was 
created accordingly.
   A clean environment for building is very easy to obtain with tools 
like poudriere and (no personal experience with this one) symth. A 
separate or virtual machine could be used too but is normally not 
necessary unless there is architectural differences or the load needed 
to be moved in some different way.