Date: Thu, 12 Sep 2024 12:41:02 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: questions@freebsd.org Subject: Re: port installation basics Message-ID: <CO1PR11MB4770E54BC55DC2425572EC19E6642@CO1PR11MB4770.namprd11.prod.outlook.com> In-Reply-To: <qZcAapFiQBQtJ9P1@aceecat.org> References: <qZcAapFiQBQtJ9P1@aceecat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB4770E54BC55DC2425572EC19E6642>