Welcome flavors! portmaster now dead? synth?
Mark Millard
markmi at dsl-only.net
Sun Dec 3 03:08:24 UTC 2017
Rozhuk Ivan rozhuk.im at gmail.com wrote on
Sat Dec 2 18:18:39 UTC 2017 :
> I dont want poudriere because I dont need ZFS, jails and other crap on my system.
> I dont want to play system administrator: keep and admin build servers at home/work.
>
> I just want update from source all my ports, make packages, and on other
> computers run portmaster to update from these packages on nfs share.
> Minimum overhead.
>
> synth - at least require specific depencies.
Poudriere certainly has more space and time use
in its way of operation. (The useful vs. overhead
is status is context dependent.)
But, I did just recently experiment with a from-scratch
try-to-build-everything ( poudriere bulk -C -a ) on
a system configuration that is just UFS based. It worked
okay. (UFS vs. ZFS has various tradeoffs for such. For
now I'm using UFS in this large-use context.)
I use UFS with poudriere-devel on a BPI-M3 armv7 board
and a Pine64+ 2GB board as well (for vastly fewer ports).
There is 2 GiBytes of RAM in each of those. For them I
use PARALLEL_JOBS=1 to be more like
ports-mgmt/portmaster and its one-builder status.
By the time indirect dependencies are traced, building
and then using ports-mgmt/poudriere-devel does
require:
misc/freebsd-release-manifests
security/ca_root_nss
where the indirect dependency status is:
security/ca_root_nss
lang/perl5.24
So normally the devel/poudriere and those
3 other ports, plus ports-mgmt/pkg itself.
I've been able to establish such a context
on powerpc64, powerpc, armv7 (previously
armv6), aarch64, and amd64. For
ports-mgmt/synth only the last two of the
5 had been directly possible.
(Last I knew aarch64 was no longer buildable,
due to the initial-binary-bootstrap stage of
the compiler toolchain involved vs. later
FreeBSD header changes.)
Note: I have experimented with
ports-mgmt/synth in the past, including
on the Pine64+ 2 GB (aarch64) before
building synth and the toolchain it is
based on was broken. But I prefer an more
uniform environment instead of using distinct
techniques. Other than that, the experiment
was interesting and worked fine.
I do not claim the following is a typical
context or that it would apply to your
specific context. But it does apply to my
context.
ports-mgmt/poudiere-devel does allow:
emulators/qemu-user-static (optional: atypical?)
For enabling potential cross builds targeting
armv7, arrch64, and possibly some others. This
leads to more dependencies when selected:
emulators/qemu-user-static (optional)
(flattened, sorted list)
converters/libiconv
devel/bison
devel/gettext-runtime
devel/gettext-tools
devel/glib20
devel/gmake
devel/libffi
devel/m4
devel/p5-Locale-gettext
devel/pcre
devel/pkgconf
devel/readline
lang/perl5.24
lang/python2
lang/python27
misc/help2man
print/indexinfo
print/texinfo
I have done amd64 -> armv7 and aarch64
cross builds of ports via poudriere.
As I remember powerpc64 is supposed to be
able to use emulators/qemu-user-static and
so could target armv7 or aarch64, although
I've not tested such.
(qemu-user-static does not work for emulating
powerpc64 or powerpc FreeBSD operation
sufficiently, so, I've not used those
types of targets for cross builds.)
I do modify poudriere's jail.sh a little to
allow a more extreme form of (for example):
A) poudriere jail -c -j jailArmV7 -a arm.armv7 -x \
-m null \
-M /usr/obj/DESTDIRs/armv7-installworld-poud \
-S /usr/src -v 12.0-CURRENT
(jail creation with some native cross-build
tools and tied to my local /usr/src/ materials .)
B) poudriere ports -c -m null -M /usr/ports
where I've prebuilt world and appropriately installed
/usr/obj/DESTDIRs/armv7-installworld-poud . The bulk
builds produce armv7 materials for that jail.
I have put copies of such world builds on the
target device and used it with poudriere on that
device as well. Thus the BPI-M3 did not have to
do its own buildworld for poudriere use in its
jail when I tried local port builds via poudriere.
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ports
mailing list