Unexpected dependencies of graphics/libGL
Luís Fernando Schultz Xavier da Silveira
schultz at ime.usp.br
Tue Jan 19 06:35:57 UTC 2016
> 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
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.
More information about the freebsd-questions