# Build port but install dependencies with pkg



## ztp (Dec 17, 2015)

I'm sometimes finding that I want to rebuild a port to enable a single option, like DEBUG, for example. Otherwise I generally use standard packages for everything else. For some ports with a lot of dependencies, I want to avoid having to build all those dependencies from source. The last time I had to to do this I crafted a one-liner to take the result of `# make all-dependencies-list` and modify that to make the packages arguments to `# pkg install -y`.

I wound up doing something like this from that port's directory:

`# make all-depends-list | cut -c 12- | xargs pkg install -y`

which cuts off the /usr/ports/ from the beginning of each line. Alternately you can use build-depends-list or run-depends-list.

This all seems a bit janky. Is there an established way of doing this that I am missing?


----------



## protocelt (Dec 18, 2015)

In short, AFAIK, no. At least there is no supported way to do this that I know of. The reason being is the official package repository and the ports tree are not synced to the same ports tree revision at this time, therefore creating a case where the dependencies may or may not be in sync with the port you are trying to rebuild causing the well known "dependency hell".

It's recommended that if you want/need to rebuild ports with non-default options, use ports-mgmt/poudriere to create your own package repository. Unfortunately AFAIK, at this time, you are on your own otherwise.

Having said that, there has been some talk about creating package flavours or sub-packages if that's a more appropriate description, though I'm not sure how far along that is or if it's even being worked on at the moment.


----------



## rabfulton (Dec 18, 2015)

ports-mgmt/portmaster used to let you do this, but has not been updated to use the new package commands :-(


----------



## ztp (Dec 18, 2015)

Interesting. I took some time to read through the portmaster code, and it is indeed disabled if the system uses pkg. Seems like it might not be to hard to add back again.


----------



## kpa (Dec 18, 2015)

ztp said:


> Interesting. I took some time to read through the portmaster code, and it is indeed disabled if the system uses pkg. Seems like it might not be to hard to add back again.



It is actually hard given that the pkg (and portmgr@) developers have raised the bar on the quality that is acceptable for the packaging utilities. The main problem is that there is no way to ask for a package to be installed via the binary packages that match certain options. For example, if you want a package of security/openssl with SSL3 turned off there's no (and there never was with the old packaging tools either) way to specify that on pkg(8) command line. The ability to use binary packages for fullfilling dependencies was turned off deliberately in order to stop telling lies to the user who blindly trusts that ports-mgmt/portmaster would do the right thing. It never did unless all the options were set at the defaults for all ports involved.


----------



## ztp (Dec 18, 2015)

There is a pull request for turning on this feature on the project's github: https://github.com/freebsd/portmaster/pull/34

It looks like bdrewery set it as a milestone for the next version of portmaster. However, it looks like he is no longer maintaining portmaster.


----------



## kpa (Dec 18, 2015)

Yeah but that would only bring back the unsatisfactory way of using binary packages for dependencies that would always install the package with default options, is that what everyone wants?

The real problem that would need to be solved is package flavors much like you have in OpenBSD. With package flavors the port maintainer could create a set of flavors such as openssl-nossl3 that would place a prebuilt variant of security/openssl in the package repository that has SSL3 turned off and there would be a way to ask for such flavor directly using pkg-install(8).


----------



## kpa (Dec 18, 2015)

I also wouldn't get my hopes up with the future of ports-mgmt/portmaster. It was very usefull and a needed utility with the old pkg_* packaging utilities because it offered repair functionalities that no other tool did. With the new pkg tools all of those functionalities are now "under the hood" and outside portmaster(8)'s scope leaving it a rather clever wrapper around the basic ports(7) system, not much else.


----------



## ztp (Dec 18, 2015)

kpa said:


> It is actually hard given that the pkg (and portmgr@) developers have raised the bar on the quality that is acceptable for the packaging utilities. The main problem is that there is no way to ask for a package to be installed via the binary packages that match certain options. For example, if you want a package of security/openssl with SSL3 turned off there's no (and there never was with the old packaging tools either) way to specify that on pkg(8) command line. The ability to use binary packages for fullfilling dependencies was turned off deliberately in order to stop telling lies to the user who blindly trusts that ports-mgmt/portmaster would do the right thing. It never did unless all the options were set at the defaults for all ports involved.



Any program that does package management should have a high standard for code quality, so they are right to be picky. As I posted above, it looks like this is was/is planned to be brought back assuming they merge the pull request I mentioned.

If you want to disable SSL in dependencies of the port you are building then it seems pretty obvious that you won't be able to depend on `--packages`. The packages are built with whatever options they were built with (whether the default packages or in a custom poudriere repository). If you need this special case then you simply ought not use that option and build everything from source.

That being said, it looks like the information is there to determine which of the dependencies would need to be rebuilt to match build requirements. Commands like `pkg search -f <pkgname-x.y.z>` and `pkg info <pkgname>` provide a list of which options they were built with. Sounds rather involved to implement though.


----------



## ztp (Dec 18, 2015)

kpa said:


> Yeah but that would only bring back the unsatisfactory way of using binary packages for dependencies that would always install the package with default options, is that what everyone wants?
> 
> The real problem that would need to be solved is package flavors much like you have in OpenBSD. With package flavors the port maintainer could create a set of flavors such as openssl-nossl3 that would place a prebuilt variant of security/openssl in the package repository that has SSL3 turned off and there would be a way to ask for such flavor directly using pkg-install(8).


Yes, this would be very useful. Much like how in Debian there are `-dbg` versions of packages that enable debug symbols. But given that this currently doesn't exist, I think the logical default is to install the dependencies with default options. I mean, that's what's built into the packages that you're asking for.


----------



## spky (Nov 8, 2020)

I've just encountered the same problem.
There is some solution. It is not very elegant, but it does what I want.

In the ports directory I run
`make run-depends-list | sort -n > ~/d-run`
and then
`make build-depends-list | sort -n > ~/d-build`

Then I can diff the output:
`diff ~/d-run ~/d-build`

First make sure that the required run-depends are installed, then I run `pkg add` on the packages from the diff output, run `make install clean` and then run `pkg remove` on the diff output again. Finally some `pkg autoremove` to clean up.

If there are some ports in between I want to have special flags, I do the same like described above.


----------

