Date: Thu, 15 Dec 2016 17:10:40 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: The ports collection has some serious issues Message-ID: <CA68139A-763C-48C2-AA43-B3B4B997560B@dsl-only.net>
next in thread | raw e-mail | index | archive | help
John Marino freebsd.contact at marino.st on Thu Dec 15 16:46:54
UTC 2016 wrote:
> For i386 and amd64 users, synth does not require more resources than
> portmaster. People on those platforms can't use "resources" as a reason
> not to use Synth. From what I can tell, portmaster people hate what
> they consider unnecessary rebuilds which both poudriere and synth
> (currently [1]) do, but it's this avoidance of rebuilds that cause all
> their problems.
Also on Thu Dec 15 16:00:47 UTC 2016:
> Anybody with a machine that doesn't have a resources to run poudriere or
> synth should not be building packages on that machine. Veterans have
> the option to use portmaster in a case like that, but it's not something
> that should be suggested to newbies.
Note: My FreeBSD usage is not from any of the main families of usage. Do
not think that I expect things to be biased for my use. My kind
of context may well be implicitly not intended to be covered by the
above.
I wonder if build tool recommendations need some breakout by
user categories rather than one grand overall recommendation.
This might be just a note of "no specific recommendation" for
some category(s).
I use my context below as a potential example.
I primarily experiment with self hosting FreeBSD activities on powerpc64,
powerpc, armv6/armv7, and aarch64, reporting issues that I find. For the
powerpc family this has focused on fairly modern clang usage for
buildworld and buildkernel -- as well as building ports. This tends to
fit me with "developer" and less with "user" in some respects.
If synth was buildable and usable on powerpc64, powerpc, armv6/armv7,
and aarch64 I likely would have tried it. (I do not want to be using
different self-hosting techniques per TARGET_ARCH but instead use
one set of techniques on all.)
Building synth would take up more time and space than portmaster but
I could have tolerated such. For the SD card contexts I tend to
have an SSD for the root file system. This likely is uncommon. Only
the old powerpc's have fewer than 4 cores/processors supported by
FreeBSD: one armv7 has 8 but FreeBSD supports only 4. buildworld with
-j 4 or so does take a long time on the armv7 machines (for example).
Of course there are large differences in performance compared to modern
amd64's.
When I tried portupgrade over a time I had problems with ruby in these
environments. (amd64 went okay.) I eventually backed off, figuring I'd
retry after some significant time in case they were temporary issues.
Other than backups/recovery media I have one powerpc64 SSD for experiments,
one powerpc SSD, one armv7 SSD (and an SD card) per single board computer
type, and the same for the one aarch64 single board computer. Definitely
not build-once/distribute-many generally. (But the armv7 context could do
a little of that as I'm currently structuring things.)
After "pkg autoremove" "portmaster --list-origins" lists 20-30 or so
ports in each case. Before the autoremove "pkg info | wc" is under 100
as I remember. I sometimes have patches to ports involved when someone
asks me to test such for something that I've reported. And because of
binutils problems for powerpc64 I use older versions from svn in the
contexts that I deal with targeting powerpc64's (that includes the
devel/powerpc64-binutils slave port). For a time devel/powerpc64-gcc
could not finish buildworld unless I used an older vintage from svn.
I really do use devel/powerpc64-gcc and devel/powerpc64-binutils and
devel/powerpc64-xtoolchain-gcc on a powerpc64: a "self hosted cross
build" of sorts. Getting devel/powerpc64-gcc installed on a powerpc64
requires a work-around because it is not a true cross-build and
some things are not the same if the target architecture is not
distinct: I'm operating outside the intended usage model. The work
around involves copying/moving some files to the right place/name
in the staging area so that installation can find them and complete.
[I also use amd64 FreeBSD under virtualbox in another operating
system. This context has more to it but is still likely less than
is typical.]
[Ignoring amd64:] If I had been able to use synth on the variety of
machines it would appear that the contribution of my time preferences
might have eventually stopped my use. (Not the number of ports
rebuilt as such but the systematic time spent.) "Might" because for
my context it is not obvious up front what my judgement might be
after a trail period.
I'm not sure what I would have done about issues like
devel/powerpc64-gcc being built and installed on a powerpc64
machine and needing a work around. Or testing patches for ports.
I did not try to figure it out since I since I discovered
synth was not an option first.
I configure to avoid "disk" space issues generally (SSD root
filesystems normally, with plenty of space).
RAM varies from 1G to 2G Bytes over the armv7's, aarch64, and some
powerpc's, but for powerpc64 there is more RAM: 8G, 12G, or 16G
Bytes.
So if I had the option for these machines only the time "resource"
would be likely to have contributed to switching away from synth
after experimenting. (Presuming the patches and workarounds were
handled.) This may be unusual for armv7 single board computers and
the like. Next most likely for resource limitations might be those
with less 2G Byte of RAM.
So far I've been able to handle what portmaster has done and have
mostly used it. I've had fewer problems than I had with
portupgrade. But I have had some issues on occasion.
[I even used a mix: portmaster to go through the configure prompts
up front and then answer "n" then use portupgrade for the actual
build based on those configurations.]
It would appear to me that some folks avoiding synth and the like
are managing tradeoffs. Others are just blocked relative to synth
itself or have run into (temporary?) problems with the
infrastructure behind some of the alternatives.
The result for me was portmaster vs. the most general/powerful
infrastructure (poudriere). At least for a time after the other
experiments I'm using portmaster for now and dealing with
whatever issues are involved.
At some point I may try poudriere in each of these environments.
But I may find that my context may just not be a good fit to the
main powerful tool, time preferences possibly being part of the
judgment: occasional extra work possibly preferred to systematic
time-taken.
===
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA68139A-763C-48C2-AA43-B3B4B997560B>