The future of portmaster

Jeffrey Bouquet jeffreybouquet at
Tue May 30 15:57:29 UTC 2017

tl/dr at bottom, repeated here,   flowchart please

On Tue, 5/30/17, Adam Weinberger <adamw at> wrote:

 Subject: Re: The future of portmaster
 To: mexas at
 Cc: rollingbits at, freebsd-ports at
 Date: Tuesday, May 30, 2017, 7:30 AM
 > On 30 May, 2017, at 8:15,
 Anton Shterenlikht <mexas at>
 >> From
 adamw at
 Tue May 30 15:03:31 2017
 >> The ports tree continues to evolve.
 Major new features are planned and in the process of being
 implemented. These changes will break all the port-building
 > oy vei
 >> poudriere and
 synth are actively developed, so they will quickly support
 the new changes. portmaster and portupgrade are no longer
 being actively developed, so it is anticipated that they
 will stop working until somebody fixes them (if at all).
 > I last used
 poudriere a couple years back.
 > It is
 much more involved than portmaster
 (obviously, these 2 tools are not doing the same job)
 There's definitely more
 work up-front to set up poudriere. You get the effort back,
 though, in long-term viability and not having to chase
 problems up and down the ports tree.
 >> So no, portmaster isn't going
 away. But, there's no guarantee that it will keep
 working. We strongly, strongly advise everyone to use
 poudriere or synth to build their ports, and then plain old
 "pkg upgrade" to handle updates.
 > because my
 experience of poudriere was mixed,
 > I
 haven't used it at all on amd64.
 pkg is great. And when occasionally I need
 > non-default options I use portmaster.
 >> The vast majority of problems reported
 on this mailing list exist only in portmaster/portupgrade,
 because they do not do clean builds. At this point,
 portmaster should only be used by people with enough ports
 development experience to understand and mitigate conflicts
 and various build errors.
 > I agree that a dirty environement is
 > the source of bad portmaster
 > However,
 to create the whole poudriere enviroment
 > to build a port a week, or maybe a month,
 > like an overkill.
 > Yes, I know,
 it's a volunteer project, things
 evolve, unless somebody steps in...
 > If my recollection of poudriere is
 > I'll need a separate ports
 > And if I only need to build a
 single port
 > with custom settings,
 I'll have to start
 > every time from
 > And if I want to use this
 single port with
 > default settings with
 my other ports, I need
 > to make sure the
 2 port trees are in sync.
 > Sorry if I don't do poudeire justice,
 it's been a while...
 You don't need separate port trees. The
 idea is to use poudriere to build ALL your ports. Just make
 a list of the ports you want, pass it to poudriere, and it
 will keep everything up-to-date, rebuild things when they
 need to be rebuilt, and give you a pkg repository so you can
 just run "pkg install foo" or "pkg
 upgrade" to keep your system running.
 Even if you do use poudriere
 to build only a few ports, it's pretty easy. Give your
 own generated packages a higher priority in
 /usr/local/etc/pkg/repos/ and you can transparently layer
 your pkg repo above the upstream repo.
 So no, you don't need separate ports trees.
 poudriere is happiest though when you let it manage its own
 ports tree, so I prefer to just symlink /usr/ports to it,
 but you can very easily use a pre-existing ports tree with
 # Adam
 Adam Weinberger
 adamw at
 freebsd-ports at
 mailing list
 To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

Sorry for the yahoo webclient not quoting the above.
If applicable.
Leaving aside my wishes for the /usr/ports/MOVED/portmanager *also* eventually back
upto speed with portmaster, even as shareware, this poudriere and even synth I think
could benefit from a flowchart...  right side differing scenarios what one's goals are 
left and work backwards thru all the things can go wrong, dotted boxes 'errors' and
arrows to the solution(s) paths, [ and  a third part of this flowchart I just thought of
...] and on the left simple boxes, like one server one lan, two servers two lan,
one server a VPN three hundred downstream 'subscriber' clients for the built ports,
and any other things, more visually explained than a much longer wiki reading.
tl/dr  flowchart please

More information about the freebsd-ports mailing list