portmaster --packages-build

N

nanotek

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

ETA:
Code: 
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.
 
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 built 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.
 
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.
 
Just to complete what have been previously said, the first line of portmaster output when this option is enabled is:
Code: 
===>>> Package installation support cannot be used with pkgng yet,
       it will be disabled
We’ll have to wait a bit more…
 
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.
Click to expand...

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:
Code: 
===>>> Package installation support cannot be used with pkgng yet,
       it will be disabled
We’ll have to wait a bit more…
Click to expand...

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.
Click to expand...

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?
 
Last edited by a moderator:
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.
 
I don't understand: what is the "sloppiness" in installing binary packages for build dependencies?
 
nanotek said:
I don't understand: what is the "sloppiness" in installing binary packages for build dependencies?
Click to expand...

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.
 
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?
 
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?
Click to expand...

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.
 
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.
 
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?
 
Just keep the golden rule in mind that you normally should not mix ports with binaries ;)

Hmm, talk about a blast from the past.
 
You must log in or register to reply here.
Back
Top