# Ports handling and dependencies



## chrbr (Dec 29, 2014)

To use the ports collection one method is to use `portsnap fetch extract` to download and extract the ports collection the first time and to invoke `portsnap fetch update` to keep it up to date. So far so good. To install, to delete or to update a port I have at least three options.

I can go to the directory of the port I like and use `make` followed by the action I intent to apply. Maybe I have to do more in case of missing dependencies. Or I use either ports-mgmt/portmaster or ports-mgmt/portupgrade with their appropriate options. The activities are somehow tracked to be able to resolve dependencies.

Does it make a difference which procedure I use in terms of further dependency handling?
End up all three options mentioned above in the same data base?
Or can I mess up things by mixing the methods?


----------



## kpa (Dec 29, 2014)

Unfortunately the methods are not equal in terms of dependency handling. The plain ports(7) system used with `make install clean` in a port directory has no other knowledge than the required dependencies to build the port in question. The other two tools mentioned ports-mgmt/portmaster and ports-mgmt/portupgrade have a little bit more knowledge because they build a rudimentary dependency graph of installed ports/packages before launching the build of requested ports, this helps them to detect which ports need to be rebuilt if the appropriate options are used such as the -r option for portmaster.


----------



## wblock@ (Dec 29, 2014)

chrbr said:


> Maybe I have to do more in case of missing dependencies.



No, the ports system handles that.  For example, say I want to install www/opera:

```
% cd /usr/ports/www/opera
% make missing
misc/compat9x
audio/gstreamer-plugins-vorbis
audio/gstreamer-plugins-ogg
multimedia/gstreamer-plugins-theora
multimedia/gstreamer-plugins-vp8
multimedia/gstreamer-plugins-bad
```

`make missing` shows dependencies that are needed but not installed.  If I did `make install`, those missing dependencies are built and installed first, then www/opera is built and installed.

Where portmaster and portupgrade are really useful is when there are new versions of multiple ports.  These utilities work out the correct order to build and install the new versions.  For example, say you have updated the ports tree with `portsnap fetch update` and then used `portmaster -L --index-only| egrep '(ew|ort) version|total install'` to see which installed ports need to be updated.  When it gives a list of more than one, the problem becomes knowing what order to rebuild them.  For example, Firefox depends on jpeg, so jpeg must be rebuilt first.  And some of the updates might depend on others.  After checking /usr/ports/UPDATING first (always!) for any manual steps, the rest can be handed off to portmaster to rebuild in the right order, which it automatically figures out: `portmaster -a`.

Once it works out that order, it uses ports system commands like `make deinstall` and `make install` just like if it were being done manually.

See Upgrading FreeBSD Ports.


----------



## chrbr (Dec 30, 2014)

Dear kpa, dear wblock@,
thank you for the detailed answers. It gives me a better idea how things work under the hood. The reason why I have raised the question is also related to my posts in Thread graphics-cinepaint-upgrade-problem.49720. Since things are not running smooth there I have asked myself if it is possible to screw up someone's system by recommending the user to launch a port-mgmt/portmaster command without crystal clear knowledge about his usual workflow. I have asked myself already if I have given a bad advice.


----------



## SirDice (Dec 30, 2014)

Sometimes ports have to be updated in a specific order, or sometimes certain ports have to be removed first. If there are any special considerations they will be noted in /usr/ports/UPDATING. You should always read that first, before trying to update anything.


----------

