Well, I finally learned of this software and gave it a try. I'll share my findings and leave it at that.
I can say: it's not for me. First of all I dislike some of the approach which I pick up as plain out arrogant. It even shows in the OP: "
Aimed at people who think Portmaster is great" as well as in the
synth(1) manual page: "
It was hoped that it would attract users of the older PortMaster and PortUpgrade ports management tools by providing them with a superior and well-maintained alternative.". Call me old fashioned but approaches like these tick me off. Live and let live is my motto, which means showing respect for other people's work.
Unfortunately for me this also sets a mindset.
So here I am in
/usr/ports/devel/apache-ant and I want to check which ports Synth found to be new. Picture me surprised...
Code:
peter@macron:/usr/ports/devel/apache-ant# synth status
Please change the current directory; Synth is unable to launch from here.
As more experimentation showed me: Synth refuses to run inside the
/usr/ports structure. I'm sure there are good reasons for that, but it's not always very desirable nor user friendly. Especially when using commands which do very little but show me the current status.
But more so because I sometimes use Portmaster for specific tasks. Including, if needed, a careful upgrade of one specific port (
-o). Which means that I'll have to specify the origin. Doable by utilizing
#pkg info -ox <name> but also by being in the physical directory itself. That of course doesn't work.
Of course I agree that this is but a detail, and I'm also not ignoring the possibility that there are most likely good reasons for this. Obviously it is important to use a tool in a proper and sometimes intended way. Still, I think it's fair to mention nonetheless given the direct comparison with Portmaster regarding "superiority" in the overall (which, for me, includes user friendliness).
So then I tried this again, this time in the proper directory called
/root/updates where I keep some of my custom made scripts (utilizing Portmaster). This time I was greeted with another error which made me seriously scratch my head:
Code:
peter@macron:~/updates#synth status
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
raised REPLICANT.SCENARIO_UNEXPECTED : /sbin/mount -t tmpfs tmpfs /usr/obj/synth-live/SL09 => failed with code 1
Why in the world would Synth rely on a (memory wasting) temporary file system while
/tmp and
/var/tmp have been carefully set up for this very specific reason? This machine I'm using isn't the most modern one, but it can maintain a package repository just fine.
Sure, I may have completely ignored any required steps to set up and configure Synth. But there's no mentioning of this requirement in the manual page. Obviously I learned about
/usr/local/etc/synth/synth.ini, also because I was curious about the
tmpfs approach and this file does have some possibly related options (
Tmpfs_workdir and
Tmpfs_localbase). Of course all the
synth(1) manualpage tells me is that I don't have to touch this file, and the file itself doesn't have a manualpage at all.
So I learned of
# synth configure, used that and confirmed my suspicions: The options
K and
L which provide me with a way to make Synth use (or not use)
tmpfs for the work area and localbase (or both of course).
Just too bad that these options apparently get totally ignored. It's the only conclusion I can come up with.
So yeah, each to their own but this is definitely not for me. Synth might be more extensive feature wise (I simply cannot say, I only base myself on what I read in the manualpage) but for me Portmaster can take care of all the tasks I need while also ensuring that I remain fully in control over what it can and cannot do. For example the option to ensure that I always have a backup package the moment it upgrades a port. I don't see anything like that mentioned in the Synth documentation. It might be a supported feature, and I cannot rule out the option that I overlooked it, but for me that also adds up to user friendlyness.
I personally prefer the Unix mindset where a program performs a small task which allows for it to become part of a bigger task. Which is exactly what Portmaster provides. It probably takes more work to configure and set it up, no arguments there, but Portmaster easily allows me to set up my own package repository and distribute those to my other servers.
It might not be an "all in one" solution, but that definitely does not make it inferior, as hinted at in your documentation.
Alas, I do wish you good luck with the project and hopefully there's still something useful in here besides my (positively meant) criticism
