portmaster, portupgrade, etc

Freddie Cash fjwcash at gmail.com
Wed Oct 4 21:11:08 UTC 2017

On Wed, Oct 4, 2017 at 1:56 PM, Grzegorz Junka <list1 at gjunka.com> wrote:

> On 04/10/2017 20:43, Mark Linimon wrote:
>> On Wed, Oct 04, 2017 at 08:13:16PM +0000, Grzegorz Junka wrote:
>>> I was trying
>>> to compile with the system that was being updated at the
>>> same time - this can't possibly work (or can it?).
>> It works somewhere between "quite often" to "nearly all
>> the time".  It can vary depending on the complexity of
> Well, that's not my experience. For me it worked occasionally at best. A
> few times the system became so broken that many applications couldn't be
> opened any more and I had to spend hours to restore it to some kind of
> usability. Even with poudriere I still manage to break the ports quite
> often by setting various options not to their recommended values - see
> defects I have been raising on https://www.freebsd.org/suppor
> t/bugreports.html But at least I am not able to install them until they
> are fixed.
> Maybe I am just too ambitious or maybe poudriere is more idiot-proof? I
> guess portmaster or portupgrade may work fine if one uses the default
> options, but in that case, hey, why bother? Just use the compiled packages!
> If you try to change some ports to non-default options, and something
> doesn't compile, portmaster/portupgrade will leave the system in half-baked
> state. And then only heavens can help...

​The nice thing about poudriere is that it doesn't affect the running
system.  The act of creating the package repo is completely separate from
the act of installing packages.  The two steps can be done on a single
system, or on separate systems.

During the creation of the package repo via poudriere, nothing on the
client system is affected; nothing is installed, nothing is uninstalled.
One can continue to use the system, which is great for desktops and
critical servers alike.

If there's an issue compiling a port in the middle of a long dependency
chain in poudriere, the process stops and you work to fix it.  Nothing you
do at this point affects any of the client(s).  If you can't get it fixed,
you don't have to worry about rolling back versions on the client(s) to get
things back to a working state.

Only once you have everything compiled and packaged up do you worry about
the client system(s).  And there, the pkg system takes over and handles
everything.  It's pretty much a "everything works or nothing gets
installed" process at that time (with very few corner cases that break

It's not bulletproof, but it's a lot safer than compiling things on the
live system where some compiler bits are picked up from the ports build
tree, while other bits are picked up from the live filesystem, while some
things are auto-detected based on other installed ports, while some things
are skipped for the same reason, etc.

Will there be situations where you want to compile directly on the client?
Maybe.  Will there be many people that need that against all other
options?  Not really.

the ports you have installed, what state the tree is in,
>> how much the ports you use are often used by others, and
>> subtle differences in changes to port dependencies.
>> This is complex enough to be indistinguishable from "phase
>> of the moon."
>> In this case I really wish I were joking.
​I used to love compiling everything on my home systems and work systems.
Then KDE upgrades kept leaving me with a broken system due to enabling some
esoteric OPTIONS that I thought I needed and portmaster would fail in the
middle of the umpteen-level-deep dependency chain.  I could usually get
things back to a working, upgraded state, but that usually left me without
a working GUI for 2-4 days.  The introduction of pkg has alleviated me of​
that need.  :)  I don't even have /usr/ports installed on my home or work
systems anymore.

After ending up with a broken server at work for the same reason I switched
those to using pkg only.  I played with poudriere back in the early days
and it was easy to work with.  But I found myself setting fewer and fewer
custom OPTIONS so the need for it diminished with time.  Debated playing
with it at work to get a custom OpenSSH package (for NONE encryption), but
I found other ways to do the same.

Freddie Cash
fjwcash at gmail.com

More information about the freebsd-ports mailing list