Unexpected dependencies of graphics/libGL

Jim Ohlstein jim at ohlste.in
Wed Jan 20 12:35:05 UTC 2016

On 1/20/16 12:51 AM, Luís Fernando Schultz Xavier da Silveira wrote:
> Hello,
> You are correct. As you described and as I pointed out before, Poudriere
> is the right tool for creating package repositories. It prevents badly
> written ports from interfering with the host system.
> However, in a system where the packages built this way are then
> installed into it, this tidyness/security benefit vanishes. This is
> my use case and, thus, for my personal use, Poudriere does not make
> sense.

I've read through this entire thread. At first I was torn between 
whether you're plain dumb or just playin' dumb.

Your answers boil down to "I don't like it because I don't like it." 
You've come up with *nothing* concrete in terms of real world evidence 
to support your suppositions. Rather you keep repeating the same rant, 
perhaps thinking if you say it enough times people will actually buy it.

Clearly you're playin' dumb and you're a troll.

Folks, please stop feeding the troll. Eventually it'll go troll elsewhere.

> On Tue, 19 Jan 2016 23:22:31 -0500
> "Michael B. Eichorn" <ike at michaeleichorn.com> wrote:
>> On Wed, 2016-01-20 at 03:14 +0000, Luís Fernando Schultz Xavier da
>> Silveira wrote:
>>> Hi,
>>> In a nutshell, the point is that the build dependencies should not be
>>> there at all. Keeping them in a jail is not a proper solution because
>>> they can still influence the host system (since the packages
>>> resulting
>>> from computations done in the jail will be installed in the host).
>> There is nothing inherently wrong about this. The jail is not insecure,
>> it runs no external services. In the case of poudriere we trust the
>> build jails in the exact same way we trust software built on the the
>> host from ports.
>> The jails are used not so much for security as for isolating the build
>> from the host environment. Do recall that jails are in a way secure
>> extensions of the chroot concept; and that chroot was developed not for
>> security, but for compling software in a controlled environment. This
>> is what poudriere does, complie software in a controlled environment.
>> Further the complied packages are not 'kept' in a jail, after running
>> poudriere all jails are stopped and compliation jails are destroyed.
>> Poudriere creates a package repository on the host system where built
>> packages are kept.
>> One big advantage to poudriere is that since you are building this repo
>> you can confirm the whole build went well before installing any new
>> package on a production system. For a complex build like x11/gnome3
>> this can be a major advantage.
>> TLDR: Poudriere is at least as secure as building from ports. (Exactly
>> as kpneal and Polytropon said.)
>>> On Tue, 19 Jan 2016 09:12:57 -0500
>>> kpneal at pobox.com wrote:
>>>> On Tue, Jan 19, 2016 at 06:34:38AM +0000, Luís Fernando Schultz
>>>> Xavier da Silveira wrote:
>>>>> 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.
>>>> Huh? When did this turn into a discussion about security?
>>>> You can do a small amount of work and have security concerns or you
>>>> can
>>>> do much more work and have the exact same security concerns. I
>>>> really don't
>>>> see how this reflects badly on Poudriere.
>>>> I thought this was a discussion about how to avoid having build
>>>> dependencies
>>>> installed when all you wanted was the run-time dependencies.
>>>> Poudriere
>>>> handles this nicely without all that mucking about with locking
>>>> packages,
>>>> keeping your ports tree in sync with the one checked out at
>>>> freebsd.org,
>>>> etc.

Jim Ohlstein

"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

More information about the freebsd-questions mailing list