On 17/02/2017 09:25, Matthieu Volat wrote:
On Fri, 17 Feb 2017 10:37:16 +0300
abi <[email protected]> wrote:
17.02.2017 00:22, Chris H пишет:
On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot <[email protected]> wrote
On 02/16/17 15:40, George Mitchell wrote:
On 02/16/17 15:33, Baho Utot wrote:
On 02/16/17 14:01, Lowell Gilbert wrote:
Baho Utot <[email protected]> writes:
On 02/16/17 06:08, Luca Pizzamiglio wrote:
I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.
If you can have it build in a clean chroot or jail then you'll get my
attention
What kind of special support?
I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.
Using chroot or jails to build each individual package
[...]
While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required. The current non-use
of chroot/jails is, for me, a feature -- not a bug. -- George
Having built and packaged linux from scratch using the rpm package
manager, I came to find that if one is building packages to be used on
multiple machines, one needs to build each package in a chroot
environment or the package could inherit things from the parent not
found in the target machine. Here by making the package unusable.
Hello. You shouldn't have any difficulty accomplishing your goal
by simply setting up a jail, and using portmaster within that jail(8).
portmaster really doesn't care where it's run. So long as it has
everything it needs to accomplish it's job(s). :-)
From my point of view, jails are overkill. Chroot should be enough and
it would be nice if portmaster starts building in clean environment.
Just dropping privileges to a dedicated user for building would be a big step,
but that's more a port feature (openbsd's ports do that, if I'm not wrong).
Yes dropping privileges would be a good *additional* step. The purpose
of the jail/chroot isn't just for security. The real goal is to provide
a reproducible, clean build environment. Lots of broken configure
scripts out there include a lot of autodetection magic. And suddenly
your binaries are link against additional libraries which are unknown to
pkg. This becomes even funnier if your application uses fork+exec per
connection. Suddenly you're left with a bound socket but each connection
dies because the worker fails to link at runtime. This was the straw
that broke the camels back for me. An other problem with portmaster is
that it creates inconsistent during the upgrade by design. Of course pkg
upgrade isn't atomic either but the time window is on the order of a few
seconds instead of minutes to hours and is far less likely fail halfway
through.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
