Re: port installation basics

On 9/12/24 13:30, fatty.merchandise677@aceecat.org wrote:
> 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?

   If the dependency is not satisfied then it will be rebuilt (ex: 
library checked by version and currently installed one is too old). If I 
recall, the dependency install should fail as it is already installed. 
This could be easily tested by 'breaking' a dependency test in a port 
(point it to a nonexistent file or too new of a version) and running 
make (for the dependencies but a general make or make install should 
trigger it). Such an issue can be triggered by version changes in the 
tree vs what is installed (official or custom built ports won't matter 
then) or ports tree bugs. Only other way I can think to trigger it is to 
have port options get changed and rebuild+reinstall ports before their 
dependencies but that should just break the installed port for what I 
can think of.

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

Correct. Otherwise it would serve little value.

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

   `make -C/usr/ports/editors/emacs -VFLAVORS` will list that port's 
flavors. I'd try `pkg install emacs@nox` to request a flavor be 
installed. I normally do not use those though and admit it seems hard to 
find documentation for pkg + flavors. My main interaction is dealing 
with things like the default version of PHP has changed and 
nextcloud-php82-29.0.5 doesn't get my custom made updates automigrating 
it to the next php version; my poudriere builds use www/nextcloud for 
the instruction of what to build so it automatically follows the default 
for php changes but pkg doesn't know. End result is I don't yet have a 
solution to avoid having to periodically and manually check & cleanup 
such leftovers. Seeing packages listed for removal without an 
appropriate replacement being installed when executing `pkg upgrade` is 
another clue Always check the output of pkg commands once removal count 
is not 0 and don't proceed unless you understand why or accept the removals.

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

   Specifically I have previously found that having a port installed 
that was not a dependency of another port modified its build to include 
other files; I think it was two kde ports that caused it and I provided 
a patch which made its way into the tree if I recall. The port's 
framework didn't modify the autotools (or whatever it was) script which 
executed during `make configure` (not to be confused with the similar 
sounding `make config` target). Upon detection, there were changes to 
what was built and installed. Files were then installed by its `gmake 
install` (or equivalent) but were never noted in pkg-plist. Removing the 
port didn't account for those extra files which I think is how I found 
it (or it caused me some other grief). If I had tried to create a pkg 
and install it on another machine, those extra files would be missing 
from the package. As far as the port's framework above it knew, no 
change had occurred as I hadn't altered any option accordingly so there 
would have been no reason to alter a plist, change an autoconf flag, etc.
 
https://cgit.freebsd.org/ports/commit/?id=5e33d1709369d21c966c8ac57443a5af99c8b8fa 
sounds like a real+recent issue & how the port was altered to no longer 
unintentionally allow autodetect of a dependency instead of following 
the port's options, or I just misunderstood things. Port maintainers and 
the build system won't have all of your same ports installed when they 
rum `make` in a port's directory. If the port uses things like autotools 
and similar systems to detect what is on your system and modify what 
they build, how they build it, and what they install and where, then you 
have different results from the what the maintainer and official 
repository saw on their run. For files to install, the list normally 
comes from a manually maintained list found in a port's pkg-plist file 
(there are exceptions). Ports will usually alter that file conditionally 
based on options from `make config` or maybe other variables like OS 
version.
   I wouldn't expect binutils port to manually detect if a system has 
elfutils present on it and change how it builds. The build servers will 
not be in a state where sometimes elfutils is installed and sometimes it 
is not so you would always get 1 package; having an option/flavor to 
change that makes a package that reliably can have it be altered for a 
build step and/or impact its recorded state for a runtime dependency.
   There are exceptions, but the majority of maintainers and the pkg 
infrastructure uses clean environments when building. If a bug is found 
for dirty environments, it should still be reported/fixed.
   Last I looked a long time ago, I found a # of ports were using 
already installed copies of files instead of using copies from the 
workdir when a port is being built (=rebuild/upgrade a port without 
uninstalling it first). Some ports failed to build until you uninstalled 
them while other times it builds even though it 'silently' used already 
install files in place of extracted/built files as it should have. That 
too is a bug and should be fixed but I assume it sometimes requires more 
extensive reworking of the tooling that the program originally uses for 
building. Maybe someday I will do another run on a few ports looking for 
that.