# Why does building a port depend on pkg(8)?



## MMacD (May 18, 2017)

That doesn't seem to make sense to me.  Where I grew up, a dependency was a requirement that a certain chunk of code be compiled (and/or linked) in from a particular library or other source.  What code could, e.g., the x11-wm/xfce4 metaport possibly need that only the pkg(8) utility can provide?   Does "dependency" mean something else nowadays?


----------



## Beastie (May 18, 2017)

It provides the infrastructure used to create the resulting package that will ultimately be installed.


----------



## phoenix (May 18, 2017)

A port compiles the software and "installs" it to the staging/ directory inside the port directory.  Then the ports framework builds a binary package using what's in the staging/ directory.  Finally, the binary package is installed using the pkg(8) utility.

IOW, in order to install *any* port, pkg(8) must first be installed.  Hence, pkg(8) is a dependency of all ports.  You can't install a port without pkg(8).

Now, you *can* build ports without pkg (the `make build` command).  But to create the binary package, and/or to install the resulting binary package, you must have pkg installed.


----------



## ShelLuser (May 18, 2017)

MMacD said:


> That doesn't seem to make sense to me.  Where I grew up, a dependency was a requirement that a certain chunk of code be compiled (and/or linked) in from a particular library or other source.


Apart from the previous comments also see ports(7). A port has basically 2 kinds of dependencies. First you have the run dependencies (listed with the `make run-depends-list` command); these are ports which are required for the port to actually function.

The other are the build dependencies. As its name implies these are ports which the port needs to be build but which can also often be removed afterwards. You can check those using `make build-depends-list`. This is also where you'll find ports-mgmt/pkg.

This dependency methodology has been around for quite a while already, it even predates pkgng itself.


----------



## jb_fvwm2 (May 19, 2017)

phoenix said:


> A port compiles the software and "installs" it to the staging/ directory inside the port directory.  Then the ports framework builds a binary package using what's in the staging/ directory.  Finally, the binary package is installed using the pkg(8) utility.
> 
> IOW, in order to install *any* port, pkg(8) must first be installed.  Hence, pkg(8) is a dependency of all ports.  You can't install a port without pkg(8).
> 
> Now, you *can* build ports without pkg (the `make build` command).  But to create the binary package, and/or to install the resulting binary package, you must have pkg installed.


Does an exception exist for installing ports to a non-standard location, for example where it conflicts with a port installed in the standard location?  [ I seem to recall that was doable in
pre-package times... ]


----------



## ShelLuser (May 19, 2017)

jb_fvwm2 said:


> Does an exception exist for installing ports to a non-standard location, for example where it conflicts with a port installed in the standard location?


Not when relying on the ports collection (and thus the package manager).

Of course you can always try to build a port and then manually perform the installation (copying) process, but even that isn't always feasible (some ports simply refuse to build whenever another conflicting port is installed).


----------



## phoenix (May 19, 2017)

jb_fvwm2 said:


> Does an exception exist for installing ports to a non-standard location, for example where it conflicts with a port installed in the standard location?  [ I seem to recall that was doable in
> pre-package times... ]



You would need to patch the port Makefile and/or pkg-plist to change the installation directory, then build/install the package from that.


----------



## MMacD (May 19, 2017)

Cheese Louise, there surely are a lot more glue joints these days.  I wonder whether the people in charge (is there anyone in charge?  The last one I knew about, fsvo "in charge", was Jordan, and he's been gone awhile) have ever thought about the costs.  Everything must be fetched anew from everywhere by everyone every time, makefiles are nested goddess knows how deep, and if anything is less than perfect--which is virtually guaranteed given the _many_ possible points of failure in practically every port--it all falls over.  Surely there must be a better way.


----------



## ShelLuser (May 20, 2017)

MMacD said:


> Everything must be fetched anew from everywhere by everyone every time


Not exactly correct. It's not that hard to set up your own repository and let your servers use that instead. When I still maintained a small server farm (VPS systems) I used to test every new update on a backup (file / test) server which would install the port but also made its compiled package available to the other servers.

Those other servers were configured to only use binary packages, and only from my own repository.

Of course that's not what you're aiming at here, but I still figured I'd mention it.



MMacD said:


> makefiles are nested goddess knows how deep, and if anything is less than perfect--which is virtually guaranteed given the _many_ possible points of failure in practically every port--it all falls over.


This isn't something new nor exclusive to FreeBSD to be honest. It applies to basically every system which relies on some kind of dependency hierarchy.

All in all I think the Ports collection works quite nicely. Sure you can have some issues every once in a while, and sometimes care needs to be taken when updating specific elements, but generally speaking I also think it does quite a good job.

Also: not every port relies on dozens of others


----------

