Is it possible to have the dialog boxes appear upfront, like they do with Portmaster, but when using regular make install?

zoltan

zoltan

Hello,
The problem I have when installing a port with "make install clean" is that the compilation gets interrupted by dialog boxes from time to time. These dialog boxes are important because they let me choose options, but I would prefer if they showed up at the very beginning of the process. I know Portmaster does this, but is there a way to do the same with the regular "make install"?
 
tingo said:
There is make config and make showconfig , but it only goes for the current port, not dependencies.
Click to expand...
make config-recursive

Code: 
     config-recursive
                      Configure OPTIONS for this port and all its dependencies
                      using dialog4ports(1).
But note this does not react to changing options in the same run. You need to run it multiple times in a row when the dependency chain changes due to options being enabled/disabled.
 
Actually (now that I had a look in /usr/ports/Mk/bsd.port.mk) there is make showconfig-recursive and make config-recursive targets too.
Update: I see that SirDice was quicker than me :cool:
 
zoltan said:
Thank you. So, that means that portmaster makes this the easiest way, right?
Click to expand...
Building on a live system will always be problematic, mostly because of build systems configuring the build based on what they detect in their environment. You could run into "automagic" (unintended) shared library dependencies, conflicts with already installed software, and lots of similar issues.

portmaster just helps you better manage these builds in the live system. It doesn't solve any of the problems attached to it.

IMHO: If you're serious about building from ports, go for poudriere, addressing these issues by building every port in a "clean" jail with nothing but the declared dependencies installed, and also offering lots of other interesting features. The -devel version just got a new dependency checker (checking actual shared library dependencies during the bulk build), and for me, this works pretty well, it seems to avoid almost all unnecessary builds, especially combined with the somewhat older feature to use official packages where applicable.
 
Thank you. I appreciate your time. Personally, I do not use ports because I have an old computer, although I understand that one of their benefits is the flexibility they offer in installing programs with custom options. I'm writing a brief tutorial and want to include information on installation a package with ports as well. I will go with the same method outlined in the FreeBSD Handbook then, just mentioning "make install." Then, if users feel they want something more specialized, I will suggest that they do further research.

OFF TOPIC: Generally speaking, mixing packages installed with "pkg" and packages installed with the Ports Collection is not recommended, right? If it's a more complex subject, we can skip it. I'm just curious.
 
zoltan said:
OFF TOPIC: Generally speaking, mixing packages installed with "pkg" and packages installed with the Ports Collection is not recommended, right? If it's a more complex subject, we can skip it. I'm just curious.
Click to expand...

I mix them all the time. I don't recall particular problems, but maybe I could work around problems quickly and don't remember. I also only have a small number of ports-compiled software in the mix and they are usually leave ports.

You could make it more safe by checking out a ports tree that matches the git hash of the current package build.
 
zoltan said:
OFF TOPIC: Generally speaking, mixing packages installed with "pkg" and packages installed with the Ports Collection is not recommended, right? If it's a more complex subject, we can skip it. I'm just curious.
Click to expand...
It's not recommended. But that doesn't mean it's not possible. The probably worst pitfall for newcomers is overlooking the fact that pkg(8) comes pre-configured to the quarterly repositories, while you typically get ports from the main branch (which you also got from the now deprecated portsnap(8)). Mixing these is recipe for disaster.

There are also lots of other pitfalls when configuring ports (options and "default-versions"). It's easy to build something that's then incompatible with other binary packages that were built with default options.

I'm getting once again back to poudriere(8). It includes a 99.9% safe way (occassional issues possible with e.g. kernel module packages) for mixing ports and packages, looking at all the relevant things to decide whether an official binary package will match the repository you're building and only in that case, take that package without building locally.

I think poudriere should be handled much more extensively in the handbook (and, strongly recommended over other tools).
 
The idea of packages+ports=bad is a simple and incorrect view. All packages in the official repository started as ports and installing a port from the ports tree with `make install` registers the installation just as it does with any other package; therefore 'package' and 'port' refer to 'package' once installed. Mixing packages of unrelated ports tree times is the worst part; for best results you should keep all packages updated to the same ports tree checkout and not mix repositories that come from different trees or different checkout times. If you do synchronize your tree to the same git checkout as another repository then you are on track. As you talk of changing build options, every build option is a change that can impact dependencies further down the line; rebuilding those dependencies against your options-modified copy would be best. Altering other settings like compiler flags may further complicate things.

Ports being built outside of a clean environment does cause issues sometimes. They will see one of those other files on the system such as during a configure stage and modify how things are built, what is built, and what is installed. Such a change does not get noted as a package dependency so you could later uninstall the offending file provider that the built port now needs and pkg will do it without removing the port too. Lack of proper pkg-plist creation means uninstallation may leave files behind. Some ports have also attempted to dynamically create pkg-plist by saying 'package everything in this directory', which quickly became incorrect when other ports also install files to that same common location; this results in any uninstall of that package removing things it shouldn't or being registered for its conflicts with other packages when no real conflict should exist.

Poudriere and other cleanroom environments also make more things buildable and with less effort to port them than when in an unclean environment. You can have one port's build dependencies that conflict with another port's build dependencies which requires uninstalling the first port's build dependencies before you can build the second port (easily accomplished with `pkg autoremove`, but a required extra step). Poudriere starts from a clean FreeBSD install with no packages added before building each port, installing dependencies from local and/or remote packages and removing it all again when it starts the next port. Unfortunately it also means it deletes and installs the same port many times over for some dependency trees and more times when there are other unrelated ports also needing it; it is a requested feature to structure things in a way where a state where installed dependencies can be reused by other builds.

Further fun comes from when a port's build is impacted by its own presence. Years ago I found there were a number of ports that would build tools to be used to perform further steps of building the port but instead of using those newly compiled tools they defaulted to using the already installed copy of them. This causes issues when you attempt to build an upgrade of the port without first uninstalling the port. This happened with a few programs where proper upgrade steps required uninstalling it first sometimes (avahi seems familiar as one but it was long ago that I last did it). I realized the problem is more widespread when I upgraded from x86 to amd64 by rebuilding in place instead of just removing+reinstalling because now any calls to locally installed copies started connecting to 32bit programs that exist but were broken because their dependencies were now incompatible 64bit programs as the build progressed.

Though easy to work around by using clean build environments, such noncleanroom build and packaging issues are all bugs that should be reported and fixed when possible.
 
You must log in or register to reply here.
Back
Top