The future of portmaster [and of ports-mgmt/synth]

Torsten Zuehlsdorff mailinglists at
Thu Jun 1 13:45:48 UTC 2017

On 31.05.2017 20:31, Adam Weinberger wrote:
>> On 31 May, 2017, at 11:28, Per olof Ljungmark <peo at>
>> wrote:
>> On 2017-05-31 02:10, Kevin Oberman wrote:
>>> On Tue, May 30, 2017 at 2:53 PM, Mark Linimon
>>> <linimon at <mailto:linimon at>> wrote: On
>>> Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
>>>> Hello, I have not followed this thread before but just wanted
>>>> to say that I use portmaster extensively, it works for us and I
>>>> would miss it if it went.  Are there actually plans to retire
>>>> it?
>>> To reiterate the status: * some extensive changes to the ports
>>> framework are coming; * these will require large changes to all
>>> the port upgrade tools; * no one has stepped forwards to offer to
>>> do the work for anything other than poudriere AFAIK. If no one
>>> does the work, at the time the large changes come, the other
>>> tools will break. People have been wanting subpackages (aka
>>> flavors) for many years; IIUC these are parts of the changes that
>>> are coming. Someone needs to step forwards and say "yes, I will
>>> do the work." mcl Since portmaster is still popult and since the
>>> only solutions that looks to be available in the near term are
>>> pouderiere or raw make, neither terribly viable for many, I will
>>> look into updating portmaster to deal with 'flavors'. This looks
>>> fairly straight forward and I my have the sh capability to manage
>>> it. (And then again, I am far from a great shell person, so I may
>>> well be wrong.) I have looked at Doug's script and it is pretty
>>> readable, but writing may require help. Can someone point me
>>> where to look for documentation on flavors? I have poked around
>>> the wiki, but to no avail. Unless there is documentation on what
>>> needs to be done, doing it will be hopeless and waiting for the
>>> packaging system to updated means portmaster WILL be broken for
>>> some period of time.
>> Let me just say that I would really, really appriciate if we could
>> keep such a simple tool. Why does it suit us? Because we have a
>> limited number of systems, and they are all different meaning that
>> we custom build for almost every task. Portmaster makes very easy
>> to build what we need on each host. Yes, it brakes sometimes but it
>> is not that hard to figure out how to get around.
> I want to reiterate that nobody is taking portmaster away from you.
> It simply has not been actively developed for years. In all
> likelihood, somebody will patch portmaster eventually. Poudriere is a
> safer, more capable tool than portmaster, and it's better to migrate
> when there's no immediate time pressure or breakage.
> The changes are not about to drop. Portmaster is not going to stop
> working tomorrow. We are bringing it up now so that you have time to
> consider migrating to poudriere or synth. If your system(s) and
> workflow make poudriere a viable option, we want to encourage and
> help you to migrate while there's no time pressure.
> Sending emails to this list about why you prefer portmaster doesn't
> change the underlying problem, though: portmaster will only be
> long-term viable if somebody actively develops it again.

Just as a short note: there is a complete rewrite of portmaster ongoing. 
Since its a beast and everything else is very hard there is no public 
evidence in case of failure. ;) Until now.

I'm currently try to convince all persons already got frustrated by 
portmaster-programming to come together and work on it. I'm also working 
at an decent automatic QA for it (and PHP and GitLab).


More information about the freebsd-ports mailing list