Why portmaster uses g++ not g++6 nor clang++?

[Stefan Esser]

Am 18.05.18 um 22:17 schrieb Rozhuk Ivan:
> On Fri, 18 May 2018 20:30:38 +0200
> Stefan Esser <se at freebsd.org> wrote:
> 
>> Sorry, this was my fault and I hope it is fixed with the follow-up
>> commit to portmaster version 3.19-10.
>>
> 
> Sorry for offtopic, but if portmaster install some build dep or run dep
> if does not mark it as autoinstalled, and:
> pkg query -e '%a = 0' %o
> show autotools, help2man and other build only crap as user install it,
> pkg autoremove
> does not remove this.
> 
> Also --delete-build-only broken.
> 
> portmaster -BgvDa -y --delete-build-only --local-packagedir=/usr/ports/packages --packages-local
> if found some package - install it, and after install create package and overwrite original.
> pkg create -n will prevent this, or additional checks, or just keep remember that pkg allready
> exist because port just installed from it.

I'm working on a completely new re-implementation of portmaster and the new
version will get these points right. Fixing the current port version is too
hard and wasted effort, since only the features and command line options are
carried over, but none of the code of the current version.

The current port master port was written at the time of the "old" package
management tools (pre PKG-NG). It took me quite some time and effort to
implement flavors support in that version, and I found that it is much
harder to maintain that version than to rewrite it with the current package
tools in mind.

The new version is already able to upgrade ports, but it lacks some of the
features of the old version (e.g. installation from local packages). But it
is already better at tracking changes, e.g. as in the recent KDE4 port and
package renaming (where both port directory and package name were changed
at the same time and the current portmaster in ports has no way to track
this change and to upgrade the affected ports).

But I'm not going to implement all features of the current portmaster. E.g.
I have no plan to implement dependency tracking via the INDEX file or the
installation of packages from a remote repository (since mixing locally
compiled and official packages is not well supported). But I plan to offer
the installation of build dependencies from locally cached packages (and
the deinstallation after they are no longer required).

But the use case you described in your mail will be covered.

I hope to have the new version ready for testing as a portmaster-devel port
before the end of June.

Regards, STefan