# portmaster --packages-build



## nanotek (Jan 25, 2014)

When can we use `portmaster --packages-build` and it actually installs binary packages for dependencies instead of building them from ports again?

ETA: 
	
	



```
FreeBSD scif 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
```
 using pkgng.


----------



## ShelLuser (Jan 25, 2014)

As far as I know it already does this, but if a package is unavailable (not present on the system's "repository" yet) then it gets buil*t* from the Ports collection as a means of 'fallback'. If you want to enforce the use of binary packages only you'd be looking at the --packages-only or -PP option.


----------



## kpa (Jan 25, 2014)

I wouldn't be so sure that ports-mgmt/portmaster actually can do that properly. For it to work as intended portmaster would have to be able to check the package's options so that they match the ones that the port would have if it was built from source. ports-mgmt/poudriere can do that but I haven't seen any indication that the same functionality has been incorporated into portmaster.


----------



## Juanitou (Jan 25, 2014)

Just to complete what have been previously said, the first line of portmaster output when this option is enabled is:

```
===>>> Package installation support cannot be used with pkgng yet,
       it will be disabled
```
We’ll have to wait a bit more…


----------



## nanotek (Jan 26, 2014)

ShelLuser said:
			
		

> As far as I know it already does this, but if a package is unavailable (not present on the system's "repository" yet) then it gets build from the Ports collection as a means of 'fallback'. If you want to enforce the use of binary packages only you'd be looking at the --packages-only or -PP option.



No, it doesn't do it anymore. See @Juanito's post for the message from portmaster and so far, every build dependency for everything I've been installing has been built from ports and not installed from binary packages:



			
				Juanitou said:
			
		

> Just to complete what have been previously said, the first line of portmaster output when this option is enabled is:
> 
> ```
> ===>>> Package installation support cannot be used with pkgng yet,
> ...



I only want to enforce use of binary packages for build dependencies, not for the actual run dependencies or the program itself. This should be available with either --packages-build on the command line or PM_PACKAGES_BUILD=pmp_build in /usr/local/etc/portmaster.rc -- it isn't.



			
				kpa said:
			
		

> I wouldn't be so sure that ports-mgmt/portmaster actually can do that properly. For it to work as intended portmaster would have to be able to check the package's options so that they match the ones that the port would have if it was built from source. ports-mgmt/poudriere can do that but I haven't seen any indication that the same functionality has been incorporated to portmaster.



According to its own configuration it should be able to use binary packages for build dependencies and it used to work with pkg_: why is it an option if not available?


----------



## kpa (Jan 26, 2014)

It's available because with the old packages the assumption was that the packages are at least somewhat usable and if they happen to work it's still lots of time saved by installing a package. Now with the new people maintaining portmaster they see a problem with this because such "sloppiness" is not what you want from any tool that is intended for automating the ports build process and that's why the same functionality is not available with PKGNG packages.


----------



## nanotek (Jan 26, 2014)

I don't understand: what is the "sloppiness" in installing binary packages for build dependencies?


----------



## kpa (Jan 26, 2014)

nanotek said:
			
		

> I don't understand: what is the "sloppiness" in installing binary packages for build dependencies?



With the old style packages you just hope that the package you install is suitable for the build you're doing. There's no way to verify that the package actually fulfills the dependencies that are required for the build to succeed. I guess when the PKGNG team took over the maintainance of portmaster they didn't want to change the --packages-build option for the old style packages even if it does the wrong thing in many cases.


----------



## nanotek (Jan 26, 2014)

Even allowing for non-default build options for the port(s) being installed, how would a package not be suitable for a build dependency?

Are you saying that, depending on the options set for the port(s) being installed, build dependencies might need non-default build options, thus rendering binary packages unsuitable?


----------



## kpa (Jan 26, 2014)

nanotek said:
			
		

> Even allowing for non-default build options for the port(s) being installed, how would a package not be suitable for a build dependency?
> 
> Are you saying that, depending on the options set for the port(s) being installed, build dependencies might need non-default build options, thus rendering binary packages unsuitable?



Yes, I can not come up with a good example now but let's say a dependency (if installed from the official package repository) of the port you're building might use a shared library that is of different and conflicting version than what the port you're building requires. The only way to detect conflicts like these before installing a package is to have a mechanism, in this case the PKGNG properties for a package, to query the package for the options and the shared library dependencies.


----------



## kpa (Jan 26, 2014)

Tools like ports-mgmt/portmaster and ports-mgmt/portupgrade were originally developed to address many of the worst problems in the old package format. Now when you replace the packaging backend with PKGNG those problems are either gone completely or are no longer in the scope of the tool because the SQLite database is not something you're supposed to tamper with directly. Basically you're then left with a tool that does quite a good job at port building but the competing tools like ports-mgmt/poudriere do a superior job with the same effort.


----------



## nanotek (Jan 26, 2014)

I think I understand what you're saying. I'm really going to miss that functionality, though. I think it's time I install ports-mgmt/poudriere and build my own packages. I only have three servers, but it will surely save me time and frustration in the long run. Problem is, one is amd64 the other two are i386; I'll have to run poudriere on the amd64 to build both x64 and x86 packages, right?

ETA: What do you recommend, Tinderbox or Poudriere? Also, do you happen to know of a decent primer I can use to install and set up whichever program you suggest?

ETA: Also, I think I have a problem similar to that which you describe in your last post: how do I go about installing missing libraries for PHP?


----------



## kpa (Jan 26, 2014)

I can't say anything about ports-mgmt/tinderbox because I haven't used it. For ports-mgmt/poudriere there's a HOWTO by your's truly here on the forums that should get you started pretty quickly: http://forums.freebsd.org/viewtopic.php?f=39&t=38859.

Yes, if you want to build both amd64 and i386 packages you'll need an amd64 host.


----------



## nanotek (Jan 26, 2014)

Nice. Thanks, @kpa.


----------



## morbit (Jan 11, 2018)

The time is now it seems.


----------



## ShelLuser (Jan 11, 2018)

Just keep the golden rule in mind that you normally should not mix ports with binaries 

Hmm, talk about a blast from the past.


----------



## morbit (Jan 12, 2018)

`portmaster --packages-build --delete-build-only`


----------

