Date: Tue, 19 Jan 2016 06:23:45 +0100 From: Polytropon <freebsd@edvax.de> To: =?ISO-8859-1?Q?Lu=EDs?= Fernando Schultz Xavier da Silveira <schultz@ime.usp.br> Cc: kpneal@pobox.com, freebsd-questions@freebsd.org Subject: Re: Unexpected dependencies of graphics/libGL Message-ID: <20160119062345.5402e98b.freebsd@edvax.de> In-Reply-To: <20160119050806.cd08ca0687e76a4b09a701e3@ime.usp.br> References: <20160117031923.ce1f36547351bf07b6fff9a0@ime.usp.br> <20160117070715.1c33732b.freebsd@edvax.de> <20160117162018.964db3b1f2f2133242773e78@ime.usp.br> <20160117220247.69e6774f.freebsd@edvax.de> <20160118161235.GA92637@neutralgood.org> <20160119050806.cd08ca0687e76a4b09a701e3@ime.usp.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Jan 2016 05:08:06 +0000, Lu=EDs Fernando Schultz Xavier da Silve= ira wrote: > That is a very cool idea. However, it does not make sense to me. > From a security point of view, it is not an improvement because malware > in the build dependencies could still affect the results of the > compilation within the jail and hence the final binaries and pkg > scripts. 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. > Furthermore, theoretically if an uncessessary dependecy can break the > vanilla system, it can also break it for the same reason with this > trick (it is just less likely). 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. > Also, the build dependencies will be built over and over again > inside the jails during updates (and there are a lot of them). This also applies to regular port usage - unless, of course, you are forcing non-standard behaviour (like keeping an old library via "pkg lock"). > So, while Poudriere is useful for building packages from the point of > view of the FreeBSD infrastructure (who does not install the packages > itself), it does not make sense to me for a system that will be > installing the packages. 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. --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160119062345.5402e98b.freebsd>