# pkgng usage, Problem with Postfix options (SASL, TLS)



## Radibor (May 1, 2014)

Hello,

I just started using PKGNG. Now I have a problem regarding options usually modified when installing from source via the Ports tree (`make config` options). I managed to switch to PKGNG and updated all installed packages with `pkg upgrade` etc., but then I realized that Postfix wasn't working as expected any more and the mail log showed that SASL and TLS are enabled but not compiled into Postfix. So my question is, when I want to used a package, e.g. Postfix with non default options (in this case SASL and TLS), how I can install a package via pkg install that contains these features? I doesn't look like options can be specified in the pkg install command and I couldn't find any information about different Postfix packages compiled with other option sets. To get Postfix working again I reinstalled it from source using `make config` to enable the options and performing a `make reinstall clean`. But that's a quite unstable situation now, the next time I run `pkg upgrade` for whatever reason (e.g. to update other packages) Postfix will be replaced with the PKGNG version that does not contain SASL and TLS and my mail server is fu**ed again.

At the moment it seems to me that PKGNG cannot be used if you want to install a single package for which you require more than the default options, at least not without risking to get it replaced with a non working one in the next `pkg upgrade` run.

Regards,
Radibor


----------



## SirDice (May 2, 2014)

Radibor said:
			
		

> So my question is, when I want to used a package, e.g. Postfix with non default options (in this case SASL and TLS), how I can install a package via pkg install that contains these features?


You don't. Package dependencies/options are set in stone and cannot be changed. The solution is to build from ports or build your own repository (very easy to do).


----------



## Radibor (May 2, 2014)

Hello, thanks for your reply.

I assume that building your own repository would allow you to e.g. build with your own preferred options from source and then create a binary package which is added in the custom repository from which it can be installed using pkg. But this would not help me considering the pkg upgrade feature to check for and install new versions available as if a new source is available I would have to create a new binary package which is no benefit, right? (At least if I'm not using the custom repository on multiple machines.) So I understand that pkg upgrade is more useful if you have a network of multiple machines which all use a custom repository to keep those systems up to date by maintaining the custom repository and I have to use portmaster to check for updates and install newer versions from source?


----------



## SirDice (May 2, 2014)

Radibor said:
			
		

> I assume that building your own repository would allow you e.g. build with your own preferred options from source and then create a binary package which is added in the custom repository from which it can be installed using pkg.


Yes.



> But this would not help me considering the pkg upgrade feature to check for and install new versions available as if a new source is available I would have to create a new binary package which is no benefit, right? (At least if I'm not using the custom repository on multiple machines.) So I understand that pkg upgrade is more useful if you have a network of multiple machines which all use a custom repository to keep those systems up to date by maintaing the custom repo and I have to use portmaster to check for upates and install newer versions from source?


Keep in mind the official FreeBSD repositories are only rebuil*t* once a week. If you have your own repository you can rebuild it as much and and as many times as you like. Added bonus, you have much better control over your updates and when they occur.


----------

