How to manage 'options' easily and globally?

D

Daniel Tourde

Hello,

Coming from the Linux Gentoo world, I want to easily have an overview over all options and easily be able to configure them (in other words, something like 'ufed' with gentoo's portage).
Is there anything like that in the FreeBSD world?
I tried ports-mgmt/lsknobs and ports-mgmt/portconf without much success. To understand the syntax and manually edit make.conf for each port seems crazy... Not so many example on the net either....

Best regards

Daniel
 
Daniel Tourde said:
To understand the syntax and manually edit make.conf for each port seems crazy.
Click to expand...
Yes. Of course, that is usually an indicator that something has been misunderstood.

Rather than try to force FreeBSD to do it the Gentoo way, best to understand the FreeBSD way first. Options are usually set with menu selections in each port. Global options that the user wishes to set for all ports can be set in /etc/make.conf. For example, I don't use CUPS, so I have this in /etc/make.conf:
Code: 
OPTIONS_UNSET=CUPS
When ports are built, any port with an option to use CUPS will have it deselected.
 
Is there any complete list of global options that I can look at?
How do I know that a local option is also a global one?
The choice I make with menu selection for each port can them be automatically saved to menu.conf? I found them in /var/db/ports. Is the syntax of the options file compatible with make.conf?
 
Daniel Tourde said:
Is there any complete list of global options that I can look at?
Click to expand...

You'll find them in /usr/ports/Mk/bsd.options.desc.mk.

Don't go crazy with sticking things in your "OPTIONS_UNSET" line in /etc/make.conf; if you do, you'll probably end up un-setting options that don't exist for any ports you have installed anyway. It's also conceivable that you'll want an option for one port, but not another--say, if you want a music player to support codecs that your video player doesn't need. Frankly, it's much easier, safer, and more convenient to set options for each individual port. You only need to do it once.

EDIT: In light of the OP, I should clarify that I mean setting options for individual ports via make config-recursive, or configuring and installing ports with ports-mgmt/portmaster or ports-mgmt/poudriere, not setting the options individually in /etc/make.conf

Daniel Tourde said:
How do i know that a local option is also a global one?
Click to expand...

"Global" just means "true for all ports." That's only the case if you set or un-set an option in /etc/make.conf.
 
You can override settings per port in /etc/make.conf. I'm quoting /usr/ports/Mk/bsd.options.mk:
Code: 
# These variables can be used in make.conf to configure options.  They are
# processed in the order listed below, i.e. later variables override the effects
# of previous variables.  Options saved using the options dialog are processed
# right before OPTIONS_SET_FORCE.  When building a port a dialog to configure
# options will only appear if there are new options, i.e. options which have not
# been configured before either using the option dialog in a previous build or
# using the variables below.  You can force the dialog to appear by running
# "make config".
#
# OPTIONS_SET                   - List of options to enable for all ports.
# OPTIONS_UNSET                 - List of options to disable for all ports.
# ${OPTIONS_NAME}_SET           - List of options to enable for a specific port.
# ${OPTIONS_NAME}_UNSET         - List of options to disable for a specific port.
#
# OPTIONS_SET_FORCE             - List of options to enable for all ports.
# OPTIONS_UNSET_FORCE           - List of options to disable for all ports.
# ${OPTIONS_NAME}_SET_FORCE     - List of options to enable for a specific port.
# ${OPTIONS_NAME}_UNSET_FORCE
#                               - List of options to disable for a specific port.
You can get a ports' OPTIONS_NAME with make -V OPTIONS_NAME. To get a list of options for a port (and to verify that what you have set/unset had an effect) you can run: make showconfig.
 
Be aware that there are still guides around written with the old OPTIONS_NAME syntax. The syntax was changed recently because the old names were never quite unique and had to be changed. For example you have to now write:

Code: 
mail_mutt_UNSET= SASL DOCS XML

The older way was:

Code: 
mutt_UNSET= SASL DOCS XML

Basically the OPTIONS_NAME values are now category_port to avoid ambiguities.
 
Ok. I think i got the Idea. Is there anyway to automatically copy the option settings stored in /var/db/ports to make.conf?
 
Daniel Tourde said:
Is there anyway to automatically copy the option settings stored in /var/db/ports to make.conf?
Click to expand...

Not that I'm aware of. But again, setting build options via make.conf is best done sparingly. This is my entire make.conf:

Code: 
######################################################################################
###  COMPILATION
######################################################################################

CPUTYPE?=corei7-avx
MAKE_JOBS_NUMBER=5
MAKE_JOBS_UNSAFE=yes
NO_CLEAN=yes
DOC_LANG="en_US.ISO8859-1"

######################################################################################
###  PORTS OPTIONS
######################################################################################

OPTIONS_UNSET=DOCS EXAMPLES HAL IPV6 NLS TEST VDPAU
OPTIONS_SET=EMACS GVFS2 GTK3 VAAPI XFT ZSH
QT4_OPTIONS=QGTKSTYLE

However, I use alternate build options for many (most?) ports. I just don't see the point in micro-managing one file when dealing with options that are only set for one port, or having to manually edit a file every time the options change with a new port version.
 
ANOKNUSA said:
Code: 
MAKE_JOBS_NUMBER=5
MAKE_JOBS_UNSAFE=yes
Click to expand...
The second one overrides the first. MAKE_JOBS_UNSAFE effectively means "this port fails to build with multiple jobs, so use only one". And this setting should almost never be needed now, it was from a time when the ports tree was converted to use multiple jobs years ago. (Yes, it is mentioned when a port fails to build. That mention is misleading and should be changed.)

Setting that in make.conf affects all ports, so they will all be built with only one job.
 
I don't recall where exactly, but I'd read that it meant something opposite: "Use multiple make jobs even when doing so might fail." Thanks for correcting me.
 
Daniel Tourde said:
Coming from the Linux Gentoo world, I want to easily have an overview over all options... Not so many example on the net either....
Click to expand...

I too used Funtoo/Gentoo linux and especially love the fine work in Funtoo. Now FreeBSD!

Setting options globally in make.conf is especially useful when developers are collaborating in building a set of ports. You can see such an example in the ports make.conf for the PCBSD project. I also find it convenient to use that style for setting ports options on my poudriere(8) build server so that the options for a jail such as "PCBSD_current" or "FreeBSD_10_stable" are encapsulated in a single file PCBSD_current-make.conf or FreeBSD_10_stable-make.conf. In normal use of the ports tree I (eventually) find the FreeBSD approach of prompting for options as part of the build process to be super convenient; learn to use the ports() config targets.
 
garry, unless I'm mistaken, I've seen you preaching the joys of Funtoo around the Arch forums, too. Between here and the FreeNAS forums you'd be, like, the fourth or fifth long-time Archer I've seen in BSD land since I joined up here a year ago. :p
 
ANOKNUSA said:
garry, unless I'm mistaken, I've seen you preaching the joys of Funtoo around the Arch forums, too. Between here and the FreeNAS forums you'd be, like, the fourth or fifth long-time Archer I've seen in BSD land since I joined up here a year ago. :p
Click to expand...

Yes, I'm also known as "sitquietly". You can see me there on the left sitting quietly. But I guess I don't always stay quiet and have been found in other forums meowing about some of the good stuff I've found. Back around 2000 I built a xeon server with quad 10,000 rpm scsi drives and happily ran a FreeBSD server/desktop for several years. I migrated from there to Gentoo to get some video support that I wanted and could get from Linux and to allow me to run multiple xeon cpus. Of course I had been influenced by the excellent engineering of FreeBSD and wanted to find a Linux as well-conceived and executed. I also spent a couple of years or three running Arch Linux and developed my own hacked-up furball of bash/awk/icon scripts to build my own variant from sources. I crazily maintained my own fork of Arch pkgbuilds for about 2000 packages. In my system the "features" of the system were set in a global config file, like USE flags in Gentoo or options in FreeBSD. I allowed the build script for a package to declare that it "wanted" another package with specific features and the build system would resolve any cyclic dependencies by building some packages twice (once without the "wants" and finally with everything that was wanted). Arch Linux is not well engineered; it just gets a lot of work thrown at it by developers who have stubbornly kept building the latest release of each individual package every day.

I finally moved on to Funtoo and found it to be very nicely engineered. Yea, I do like Funtoo a lot. By the way an extraordinary linux, if you need linux for something (I need to run google chrome to watch Netflix movies), and want to enjoy a very nice init system and clean code, is Void Linux. Standard Void, with GNU glibc, is remarkably fast. My boot up takes about 5 seconds. If you don't need glibc then you can run Void with the more-standard, and faster, BSD-like musl libc. I dual-boot Void Linux alongside FreeBSD (soon to be PCBSD as soon as Kris releases the Jan 2016 11-CURRENT image). I get all of my work done in FreeBSD and can't imagine living again without it's features.

Best regards.
 
You must log in or register to reply here.
Back
Top