# Questions about internals of ports configuration



## dvdmandt (May 18, 2013)

Hi, I have a quick question about the ports internals. When I run `make config`, where is the configuration stored?

Also, what would be the best way to find all options for a specific port, in a non-interactive way? Do I need to parse all the Makefiles and bsd.*.mk files or is there some way to export them?

I want to experiment with pre-configuring my ports and all dependencies before building. The reason being that I installed KDE4 from ports with various customized options, which resulted in the build stalling every now and then waiting for my input. Since I wasn't constantly monitoring it, I estimate that the installation took 4-5 times longer than ne*c*e*ss*ary.


----------



## jozze (May 18, 2013)

Options are stored in /var/db/ports/, but you shouldn't fiddle around with those, unless you know what you're doing. There you have individual settings for each port, that doesn't use the default ones.

To find options for a port, [cmd=""]cd[/cmd] to its directory, and use `# make showconfig`. To see configurations for its dependencies as well, you can use `# make showconfig-recursive`, but you don't really have to be the root user to do that.

To set configurations for a port along with all dependencies before building, you can use `# make config-recursive`, but I'd suggest using a utility like ports-mgmt/portupgrade or ports-mgmt/portmaster, since you'll need it to update your ports anyway.


----------



## Toast (May 18, 2013)

dvdmandt said:
			
		

> Hi, I have a quick question about the ports internals. When I run `make config`, where is the configuration stored?


/var/db/ports/



			
				dvdmandt said:
			
		

> Also, what would be the best way to find all options for a specific port, in a non-interactive way? Do I need to parse all the makefiles and bsd.*.mk files or is there some way to export them?
> 
> I want to experiment with pre-configuring my ports and all dependencies before building. The reason being that I installed kde4 from ports with various customized options, which resulted in the build stalling every now and then waiting for my input. Since I wasn't constantly monitoring it, I estimate that the installation took 4-5 times longer than nessecary.


ports-mgmt/portmaster does that automatically but you can force it with "--force-config".


----------



## dvdmandt (May 18, 2013)

Thanks a lot! I will be sure to make use of these in my experiments.

Is there a way to import options without fiddling with the /var/db/ports files?

I am also interested in the dependency chains. I found `make depends`. Using it in my apache22 directory shows a fairly short list with entries of varying types. There appear to be dependencies on files, shared libraries and packages. I am however unable to see any obvious way to link these to ports/packages which install them?


----------



## jozze (May 18, 2013)

You don't have to run `# make depends` -- dependencies are built automatically with `# make install clean`. To see which targets you have using make, see ports(7)().

To actually get list of dependencies you can use `# portsdb -R some_port_name`, and to see which ports depend on it, use `# portsdb -r some_port_name`.

As for importing configuration files, I'd rather just set them again with `# make config-recursive`. However, maybe just overwriting them in /var/db/ports won't do any harm, IF AND ONLY IF both ports trees are at the same revision.


----------



## dvdmandt (May 19, 2013)

Oh, I had misunderstood the meaning of `make depends`, I thought it just listed dependencies without installing them. I must have tried it only on ports for which I had already installed all dependencies.

Does `portsdb -R` take into account the configuration generated by `make config`? Some of my experiments include analysis and plotting of the dependency graph and how it changes depending on configuration. For example, "why is it installing 3 additional programming languages and the entire X11 subsystem when all I wanted was PHP support in my web server?" is an embarrasingly common question I ask myself when installing FreeBSD on a new server. The reason is usually that I enable a non-standard option in my target port and leave the defaults for most of the dependencies without realizing what an explosive effect it will have.

An idea I have is to create a graph with nodes representing ports and edges representing dependencies. Different visuals would be used to indicate aldready installed ports, conflicting ports, hard dependencies vs configuration based dependencies etc. Ideally, I would like this graph to be interactive so that you can click a node to bring up its configuration, and having the graph update on changes.


----------



## jozze (May 19, 2013)

No, I think it's showing all listed dependencies, regardless of your configuration file.

As for installing other "unneeded" stuff -- FreeBSD is actually VERY efficient about them: you've got dependencies needed to run, and dependencies needed to build -- ports-mgmt/portmaster has option to delete them afterwards, or ports-mgmt/pkg has option to run `# pkg autoremove` which will do stuff like that.

Build and runtime dependencies are listed in each individual Makefile. Consult the Porter's Handbook for more information on that.

If you want to do some analysis like you suggested, it'd be best to maybe write a program that checks individual Makefile and compares it with the config in /var/db/ports. A relatively simple shell script could do it. You can also look at portmaster source code.


----------



## dvdmandt (May 19, 2013)

Don't get me wrong, I absolutely love the ports system, and even before I learned about the *-recursive options, I though it was the greatest (by far) software management system in the OSS community. That does however not mean I don't think there's room for improvements. 

I think the dependencies system works great. I do see room for improvements when it comes to understanding the effects of a specific option in a port though. 

Parsing the Makefiles does not really appear realistic after an initial look. There is way to much conditionals, includes and lazy evaluation behavior. It seems much more realistic to use my own Makefile which include the real one, with a special target that only displays the value of the relevant variables/defines. It doesn't give me all the information I would ideally want, but better than nothing. The bigger problem is that it relies much more on technical details in the internals than I'd like. I'd much rather use existing tools and commands to get the information.


----------



## kpa (May 19, 2013)

Ideally all the options for ports would be implemented using the so called optionsng system. For example this how the port for lang/perl5.14 declares all valid options in the Makefile:


```
OPTIONS_DEFINE= DEBUG GDBM PERL_MALLOC PERL_64BITINT THREADS PTHREAD \
                MULTIPLICITY SITECUSTOMIZE USE_PERL
OPTIONS_DEFAULT=        PERL_64BITINT PTHREAD USE_PERL
GDBM_DESC=      GDBM_File extension
PERL_MALLOC_DESC=       Use Perl malloc
PERL_64BITINT_DESC=     Use 64 bit integers (on i386)
THREADS_DESC=           Build threaded perl
PTHREAD_DESC=           Build with -pthread
MULTIPLICITY_DESC=      Use multiplicity
SITECUSTOMIZE_DESC=     Run-time customization of @INC
USE_PERL_DESC=          Rewrite links in /usr/bin
```

Very clean and readable isn't it? However, the conversion work to optionsng is slow and will take a lot of work from the port maintainers.


----------



## dvdmandt (May 19, 2013)

This was the only format I found, how does the old system work? Any particular port showing the old way? Anyway, the problem is not finding the options, `make showconfig` appears to give me the options in a suitable format, the problem is finding out what they affect. 

One idea is to clear all settings, get dependencies, then enable a setting at a time while recording changes in dependencies. This is not entirely correct however, since one option may affect the outcome of another. There are also some cases where there are multiple ports for a single software, for example *-nox11 ports. There also appear to be cases where a port depends on one package, unless another is installed, in which case that is used.


----------

