Questions from the "About ports and (binary) packages" howto

Running portmaster -a:

Code:
man portmaster 
*snip*
 Features:
     -a  check all ports, update as necessary

Let's try that:
Code:
root@bakemono:/ # portmaster -a
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates
===>>> Launching child to update nvidia-xconfig-460.67 to nvidia-xconfig-470.42.01

===>>> All >> nvidia-xconfig-460.67 (1/1)

===>>> Currently installed version: nvidia-xconfig-460.67
===>>> Port directory: /usr/ports/x11/nvidia-xconfig

===>>> Launching 'make checksum' for x11/nvidia-xconfig in background
===>>> Gathering dependency list for x11/nvidia-xconfig from ports
===>>> Initial dependency check complete for x11/nvidia-xconfig

===>>> Returning to update check of installed ports


===>>> The misc/qtchooser port has been deleted: No longer supported upstream
===>>> Aborting update

root@bakemono:/ #

It's broke in that regard and is up to the current version.

It shows nvidia needs updating and should go much further but aborts due to the deletion of misc/qtchooser from ports.
 
Doing a dry portmaster run (with the -n option) inside a script session can still generate a text file that can be parsed with grep and sed for usable analysis.
 
Trihexagonal said:
The misc/qtchooser port has been deleted: No longer supported upstream.
Qtchooser allowed you to choose between two qt versions (4 and 5 iirc). It's no longer needed since we have only version 5 left. If you still haveit installed you can remove with pkg delete -f qtchooser.
 
Why not use the , i think better, synth or poudriere ?
Actually, I am working on using portmaster's dry runs to create a list to feed to poudriere... But there's a lot of details to line up. For example, I'm still trying to figure out if # make config-recursive makes a difference to the list that portmaster generates.
 
I currently have 2200 ports compiled and installed with poudriere.
For instance Chromium has a build dependency on python2, so i drop it and use firefox instead, i've blacklisted python2.
That is one way to solve dependency problems.
I have qtchooser installed which sits nicely together with the other 2199 ports.
 
With portmaster I can simply blacklist a port, too. And as long I leave qtchooser on my installation available, I have no problem with ports using it. So in that case there's no benefit in not using portmaster, and switching to something else wouldn't solve anything…
 
If you still haveit installed you can remove with pkg delete -f qtchooser.
I took the advise of Tieks and issued pkg delete -f qtchooser.

I was then able to continue with portmaster -a, it completed a full scan, I approved the goahead and it upgraded and/or installed 55 programs with no problem whatsoever. I ran the command again after portsnap fetch update just to make sure and it reported all programs were up to date.

I just finished it over the ensuing time period, have invoked shutdown -r now, am back up and running and once again things are as they should be.

I've got another going through the same procedure and will probably do the same on all my machines. They have all exhibited the same behavior, whether that's due to my own methodology or not, that's what needs to be done to bring them all back in line.
 
With portmaster I can simply blacklist a port, too. And as long I leave qtchooser on my installation available, I have no problem with ports using it. So in that case there's no benefit in not using portmaster, and switching to something else wouldn't solve anything…
I seems logical that dependencies cannot be solved by buildtools.
Only blacklisting or disable certain options on certain ports.
 
Case study in why you shouldn't mix ports and packages:
 
Back
Top