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 _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"