Synth dependencies rebuild overhead ?

I'm not sure what you mean about the other thread.
When marino@ was insisting that attaching a build log will help to get a new port committed, I pointed out that there could be reason to not be so strict, portmaster and portupgrade, considering his opinion "based on garbage" they qualify for removal from port tree, even when the build logs would be positive.

Of course, I know there is a section about poudriere, I hope there will be one about Synth too.

I can clearly see that the initial design of portmaster and portupgrade are meant to install/upgrade ports on a single system, while poudriere and synth are designed to build a local repository.

Although there is a difference, I'm understanding that this is a theoretical difference, and that in fact a proper update from port tree require to build/install some port "subtree". (subtree based on dependency relations, not on filesystem hierarchy).

Now, both kpa and marino@ in different ways are suggesting that portmaster and portupgrade are unable to properly upgrade the "subtree", while synth and poudriere can manage that properly, and in fact kpa highlighted that poudriere has been improved to rebuild all the dependent packages, something that neighter portupgrade nor portmaster do on their own.

I have yet to understand the technical reasons in the deep details, but I trust their opinion until proven wrong.

If what they are saying is correct (there is the need to rebuild a whole subtree), I can not see how portupgrade or portmaster can be trusted to do the job.
 
Configuring synth to use ccache and to fetch prebuilt packages whilst making sure that /var/db/ports only has options configured for ports that you absolutely want to customise goes a long way to making synth work pretty quickly for you. I've been using it for 6 months or so now and I can totally see why the old portmaster way of doing things is wrong.

It's a shame that the official handbook doesn't just mention synth or poudriere and removes all mention of portmaster.
 
  • Thanks
Reactions: ASX
Configuring synth to use ccache and to fetch prebuilt packages whilst making sure that /var/db/ports only has options configured for ports that you absolutely want to customise goes a long way to making synth work pretty quickly for you. I've been using it for 6 months or so now and I can totally see why the old portmaster way of doing things is wrong.

It's better to have your own file equivalent to /etc/make.conf with all options listed in there which can be used by poudriere. I don't use synth but I'm sure it does have one as well.

Synth hasn't one, supposedly because is younger and because some people jugde "9 months" like being a tiny amount of time!

Synth is new with many features and the developer, Marino@, is very active on this forum which is good. The only main difference is that synth build its packages based on the host system in chroot. Poudriere build packages in jails based on different FreeBSD releases apart from its host system. So poudriere is better if you have multiple servers with different FreeBSD releases.

Anyway I stopped using portmaster or portupgrade since pkg, poudriere and synth are beginning to replace it as they are much more reliable without littering the system with orphaned dependencies or breakages.
 
To my knowledge, nobody has submitted such a section.
My apologies, clearly I'm failing at trying to be ironic.

The 9 months approximately are the time that synth is in port tree ... as above, is a tiny amount of time, clearly insufficient to mention about ports-mgmt/synth existence.

"ports-mgmt/synth is an alternative to ports-mgmt/poudriere build system, right now limited to i386/amd64 arch targets."

That's all is required for a start. In my view, of course, the man page already provide lot of additional info.
 
The only main difference is that synth build its packages based on the host system in chroot. Poudriere build packages in jails based on different FreeBSD releases apart from its host system. So poudriere is better if you have multiple servers with different FreeBSD releases.

I need to emphasize again that Synth can easily support multiple FreeBSD releases. While there are specific advantages that poudriere has over synth, this feature is definitely not one of them. One should not use that reason as a differentiator.
 
The 9 months approximately are the time that synth is in port tree ... as above, is a tiny amount of time, clearly insufficient to mention about ports-mgmt/synth existence.

Synth is an excellent tool, and marino@ has been diligent about addressing potential problems here in the open, while helping people learn how it works and how to use it to their advantage. That said, no, 9 months isn't necessarily enough time for a third-party party tool to be given "semi-official" status. I don't really see a problem with mentioning it in the Handbook, since it's been the official build tool for DragonFly for some time. But Poudriere is the official build system for the FreeBSD project, so it should be given more weight.

From a documentation standpoint, too, the entire section on ports and packages would need to be modified in such a way that newer users could easily follow the logic from installing and removing single ports or packages; to manually upgrading ports and packages; to understanding how these two tools (Poudriere and Synth) work, and what differentiates them; to using these two tools (Poudriere and Synth) to manage large numbers of ports/packages. In short, updating the Handbook with the intention of promoting these tools as the primary means of managing ports would involve more than simply adding an "official seal of approval" to the Poudriere section and tacking on a page about Synth---the whole chapter would need a partial rewrite covering all those things and stringing them together.

I've been meaning to get seriously involved with DocProj for a while, and would be willing to work with marino@ and wblock@ to touch up and put together the English sections, but then next couple weeks are somewhat full and I still need to familiarize myself with the mark-up the project uses. :( Sorry for the cop-out.
 
  • Thanks
Reactions: ASX
I need to emphasize again that Synth can easily support multiple FreeBSD releases. While there are specific advantages that poudriere has over synth, this feature is definitely not one of them. One should not use that reason as a differentiator.

My apologies for not being aware of recent changes to synth, so what are the major differences between synth and poudriere?
 
That said, no, 9 months isn't necessarily enough time for a third-party party tool to be given "semi-official" status

Thanks for your (present of future) contribution, however let me disagree about that: 9 months are a large amount of time in my view, especially considering the context where it seems that the use of poudriere or synth can solve some issues left unattended from portmaster and/or portupgrade. And that is of primary importance at my eyes.
 
My apologies for not being aware of recent changes to synth, so what are the major differences between synth and poudriere?
This isn't a new feature, it's been there from the beginning (enabled by the profiles).

There aren't many things that poudriere can do that synth can't. What comes to mind:
  • platform agnostic. poudriere is set of shell scripts so it has no dependencies and works everwhere (although it may not be practical to run everywhere). In comparison, synth is limited to i386 and amd64 right now.
  • "cross compiling". While not true cross compiling, poudriere can support building ARMv6 packages on amd64. Synth can't do it although I don't know how much is required to support.
  • one command to install different arch/release jails (Synth can't do this for a user but can leverage it, even poudriere jails)
Synth can do things poudriere can't. Off the top of my head:
  • It seems to be 25% faster on the same hardware
  • It has the use-prebuilt-binaries feature which is pretty popular
  • the "test mode" is more useful than "poudriere testport" although the latter has more options but it's not a mainstream feature
  • ncurses display is pretty
  • web display is pretty

Another design difference is that synth overwrites logs while poudriere generates new ones indefinitely. This is intentional because full runs consume 1.5 - 2.5 Gb and people can actually run out of diskspace if they aren't cleaned periodically. To save logs in synth, an external command would have to snapshot them or something.

If I come up with the "aggressive multipass" build then synth would have a clear performance advantage where it would rebuild 5 packages when the other rebuilds 150 (e.g.)
 
I've been meaning to get seriously involved with DocProj for a while, and would be willing to work with marino@ and wblock@ to touch up and put together the English sections, but then next couple weeks are somewhat full and I still need to familiarize myself with the mark-up the project uses. :( Sorry for the cop-out.

It's been on the "to-do" list to create a full handbook for Synth and publish it on github pages. At that point, the freebsd handbook would mostly link it other than most basic of commands. I haven't been pushing freebsd docs because A) there's inertia there (possibly intentional) and B) I need to do my part first.
 
Back
Top