# Installing applications from ports



## golpemortal (May 10, 2022)

I just got myself a new ThinkPad and I have installed Freebsd 13.0 and this time I wanted to install all my apps via ports and not binary and my question is - Should I install multiples ports like this


```
# cd /usr/ports/x11/xorg/ && make install clean BATCH=yes && cd /usr/ports/x11-wm/i3/ && make install clean BATCH=yes && cd /usr/ports/x11/i3status/ && make install clean BATCH=yes && cd /usr/ports/x11/i3lock/ && make install clean BATCH=yes && cd /usr/ports/x11/dmenu/ && make install clean BATCH=yes
```



I am trying to do others chores around the house 

Will this work without any issues ?


-Golpemortal


----------



## Geezer (May 10, 2022)

That's one way of doing it. Maybe do not use the `&&` and do each stage separately so you can see what is going on.

Alternatively, you can use a ports manager. There are many and you can read about them in the handbook. I use ports-mgmt/synth

As an aside, your subject "_your input needed_" could go for most threads here. You could change it to something more about the thread itself.


----------



## im (May 10, 2022)

golpemortal said:


> Will this work without any issues ?


No. Some ports may become to be broken.
All your process will fail on the first error because of &&
Rewrite your script for processing a list of needed ports independently one from other.

Read the full manual ports(7)

```
config-recursive     Configure OPTIONS for this port and all its dependencies using dialog4ports(1).
```
Make target 'config-recursive' can save your time.
It download and configure all dependencies BEFORE the building process.
So you will can run 'make' and have a rest.

To prevent unpredicted delays of the process you can use the scenario:
cd /usr/ports/*/somelargeport
make config-recursive
<Complete 'config' of the port and all dependencies, and you will not interrupted later>
make install
[make clean]

If you will build ports via remote connection then I advice you to use a 'terminal multiplexer' like sysutils/screen or sysutils/tmux.
It allows you to detach a remote console session without interruption of a build processes.
Also it makes the process independent from a management computer.


----------



## sidetone (May 10, 2022)

ports-mgmt/portmaster will prompt for all of the options at the beginning. The config file for portmaster(8) is /usr/local/etc/portmaster.rc. To save some time, it can use packages for build-only dependencies, which doesn't change options and doesn't have much effect on the way a built program runs. `PM_PACKAGES_BUILD=pmp_build`

Also, you can put the list of ports in a file, with a space or new line separating them. use the category with a / and a port. It works for ports, and for packages, while packages will ignore the category and /.

```
x11/xorg x11/xdm
x11-wm/i3
```

Then, you can use `pkg` or `portmaster `cat pkg-list.txt``. (The ` is the button of SHIFT ~, it's not the single quote.)

Also, for consistency in options, these can be put into make.conf, for instance:

```
OPTIONS_SET+=   PORTAUDIO SNDIO \
                LIBXCB

OPTIONS_UNSET+= PULSEAUDIO JACK AVAHI ALSA NAS PANGO CANBERRA \
                LIBX11 LTO
```


----------



## golpemortal (May 10, 2022)

I want to install with default values and don't want the system to prompt me the blue screen for options.... Is BATCH=yes a good option?


----------



## im (May 10, 2022)

It is no reason to make software from ports with default values.
Just use FreeBSD packages.
Trust me.


----------



## zirias@ (May 10, 2022)

Agree with im. There's just one little exception: ports/packages containing kernel modules (they're typically named `*-kmod`). In FreeBSD, the ABI is kept stable for the whole lifetime of a major release (e.g. 13.x), but this is not necessarily true for the in-kernel ABI. So, a kernel module built on e.g. 13.0 might be broken on 13.1. In the short time period when two minor releases of the same major release are supported (IIRC, 3 months), this can be a problem. There's only one repository for each major release, and the official packages will be built on the _older_ minor release until it's EOL. So if you already use the _newer_ release during this time period, you might want to build `*-kmod` ports yourself.

But apart from this exception, building yourself with all default options makes no sense. You'll end up with binaries that are bit-by-bit identical to the official packages – except if some "automagic" dependency is accidentally picked up by a build on your machine. The best way to avoid that is building packages in isolated environments – the already mentioned "synth" does exactly that, as well as FreeBSD's "standard tool", ports-mgmt/poudriere.

Some people seem to think modifying `CFLAGS` et al to build binaries "optimized" for your local machine was a valid reason for building yourself, even when using default options. An idea that seemed to be popular with Gentoo users, btw . Well, that's not a good idea. In almost any case, performance benefits aren't even measurable. But there's a relevant risk optimizations lead to broken software. Just don't do it.

The only valid reason for building yourself is using custom build-time options, either by setting port-specific options or by modifying `DEFAULT_VERSIONS`. And if you start doing this, use a tool (poudriere or synth) that builds packages in isolated environments from the ports, so you can install them with `pkg`, that's the best way to keep your system maintainable.


----------



## golpemortal (May 10, 2022)

Thanks guys... I will follow your advice and do the FreeBSD packages.


----------



## astyle (May 10, 2022)

I agree with Zirias ,  he's got a good post that hits the important points.

I'd like to point out that the Handbook discourages mixing ports and packages. The way I deal with that is to make the decision to stick with either BEFORE installing FreeBSD at all. I re-installed FreeBSD many times over before finally settling on ports. For me, that was a learning experience, and I'm savoring the results of those efforts. Yeah, it takes time and effort, but you'll get to savor the results afterwards.


----------



## zirias@ (May 10, 2022)

astyle, sticking with _one_ option is a safe way to avoid trouble, cause there _are_ pitfalls when "mixing". But still, you can do it.

The single biggest pitfall is quite easy to sort out: mixing them from different branches (typically ports from "latest" with packages from "quarterly") will _never_ work well.

I think there's a "gold standard" for mixing: Use a tool that builds a local package repository, but _can_ put pre-built binary packages in there if it detects there would be no difference. ports-mgmt/poudriere-devel can do that, as well as AFAIK synth, although I never tried the latter myself.


----------



## grahamperrin@ (May 19, 2022)

astyle said:


> … the Handbook discourages mixing ports and packages. …



If the discouragement is too blunt, then the Handbook should be improved. 



grahamperrin said:


> <https://old.reddit.com/r/freebsd/comments/sn44xj/-/hw6tblw/?context=1> _mixture by design_
> 
> <https://old.reddit.com/r/freebsd/comments/sn44xj/-/hw6skbf/?context=1> an example.











						Solved - FreeBSD Handbook improvement surveys – announcement and background
					

For the benefit of people who do not have a full subscription to freebsd-announce:       Pau Amma invites responses to his e-mail:    The FreeBSD Foundation contracted me to develop a prioritized plan for improving and updating the FreeBSD Handbook. For the first stage of this project, I have...




					forums.freebsd.org


----------

