Unexpected dependencies of graphics/libGL

[Luís Fernando Schultz Xavier da Silveira]

Hello,

> But this is not different from how ports are being built in
> the regular ports tree: Compilation tools could be compromized
> or package content could be affected. The typical "make install"
> will generate a package which is then installed via pkg.

Indeed, it is not different, and that is my point.

> It's easier to revert a jail than a whole system. Additionally,
> the jail is separated from the system so no harm can be done
> there.

If the extra dependencies break the jail, the output packages can be
malformed and, when installed, break the host system.

> This also applies to regular port usage - unless, of course,
> you are forcing non-standard behaviour (like keeping an old
> library via "pkg lock").

I do not think so. With regular use, build dependencies are only
rebuilt when updated.
To be fair, I never used Poudriere and do not know how it handles
this, so please disregard my comment.

> In this case, check "pkg lock" and "pkg unlock". Maybe a custom
> solution is possible for you: First lock all packages except
> those that you really want to be affected by an upgrade, then
> run "make configure" and "make install" (which, as I said, causes
> a "pkg install" step), and then unlock things again if you wish.
> If your system contains lots of software installed from ports,
> and you're not planning to install from packages, this is not
> a big problem, I think. Only the case "mixing ports and packages"
> is still something where you need to pay attention to several
> side effects.

Indeed. I avoid mixing ports and packages. In each jail I choose one
method. But for the host I prefer ports.