portmaster, portupgrade, etc

Ernie Luzar luzar722 at gmail.com
Wed Oct 4 20:39:29 UTC 2017

Michael W. Lucas wrote:
> Hi,
> I'm doing tech edits on the new edition of "Absolute FreeBSD," and
> stumbled into what's apparently a delicate topic.
> Some of my reviewers are happy I included portmaster in the book.
> Some reviewers beg me not to include it.
> Unfortunately, people will be reading af3e and considering it
> definitive for the next several years. So I have to get a feel for
> where things are going. :-/
> I've read a couple threads on portmaster's current problems/growing
> pains and its looming difficulty with forthcoming flavors.
> I've been a happy portmaster user for many years now. All things being
> equal, if its future is still being debated I'm inclined to keep it in
> the book.
> Poudriere really needs its own small book. Yes, you can do simple
> poudriere installs, but once you start covering it properly the docs
> quickly expand. My notes alone are longer than my af3e chapter
> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> 2018).
> Truly, I'm not looking to start a flame war here. I only want a bit of
> guidance on The Future...
> ==ml

Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 2 
years ago with their development of a better pkg system.

The package system with flavors will cover 90% of the user community
needs. The remaining user's requirements are edge cases. Tools like 
portmaster and portupgrad and even the native ports system usage on 
personal machines will fad away. The ports system will mature into the 
development system in the path to get things into the package system.

You adding details on these port system tools will only give the reader 
the impression that they are still popular and being actively supported 
thus working against the intended direction Freebsd package system is 
headed. Making it even harder to get users to move forward.

Don't let the few old school die hearts who are afraid of any change and 
make the most noise influence you. There will always be edge case user 
who think their needs out weight what is best for the group.

Remember that your updated book will become a bible for many years and 
many readers. Don't include items that are now on the edge of being 

Another candidate is JAILs  IE: the old way of jail definition was in 
rc.conf the new way being jail.conf. The jail.conf method was 
introduction was at RELEASE 9.0 and here its 11.1 and still the old 
school users fight to retain both ways. Hoping that with 12.0, support 
for jail definition in rc.conf will be totally removed.

One last though. The problem with the Freebsd handbook is that it reads 
like a list of reminder notes. The reader is expected to already have a 
well defined understanding of the subject being read about. The past 2 
years a great amount of effort has gone into bring the handbook up to 
date with the current status of the operating system. But it is a very 
far cry from a teaching aid.

Please take the time to rework the original "Absolute FreeBSD" content 
into something that is usable as a teaching book. You must assume that 
the only thing the reader knows about Freebsd is how to spell the word 
Freebsd and build the content from there.

Good luck.

More information about the freebsd-ports mailing list