The ports collection has some serious issues

[abi]

>> 2. It doesn't provide dialog for port options, so
>> 2.1 I don't receive information if port options have changed. I don't
>> know what else will be pulled to my system after port tree update.
>
> which of course is a false statement.
> If you set port options which then change, Synth will stop and tell 
> you to reconfigure or remove the saved port options.

Not at all. For example, let's assume I go recommended way and have 
options for ports with not default settings. Let's say, I have perl with 
default options (no OPTIONS file). Let's say port maintainer adds new 
option, [NSA Backdoor]
Perl will be silently compiled with that option, right? This is not 
paranoia, here is example from real world - I rebuilded one port and 
noticed new option - [USE GCC] with default On. I really don't want that 
gnu beast in my system, so I investigated the problem and suggested 
patch to compile port under clang. Everyone happy. We can search PR 
database if you don't believe me.
If I was synth user, I've ended with gcc pulled.

>
>> 2.2 If I make option files for all ports, synth fails to rebuild
>> repository if port and it's options are out of sync.
>
> yes, of course.  If you give it impossible instructions, it will stop 
> and ask you to fix them.  Any reasonable person would want to be 
> informed when the options are incorrect.  Did you also notice that 
> extended use of portmaster resulted in dozens of obsolete options 
> files that you weren't aware of?  So your criticism here is that you 
> think Synth should just ignore these bad configurations?
No, I didn't notece obsolete options. Maybe my /var/db/ports is a 
complete mess and I should cry in tears. but when portmaster encounters 
new options it invokes dialog4ports and let me fix the problem. If this 
leaves some staled OPTIONS file, I'd say it's portmaster bug, not design 
feature. We all know that portmaster is in rather poor shape.
>
>> 2.3 When port infrastructure switch to newer default version I must be
>> aware that this change occur and set damn options for new default port.
>
> Another false statement.
> The ports framework has a DEFAULT_VERSIONS support which you can 
> override via a profile mk.conf, just as poudriere does.  Doing so 
> avoid surprises.  There is also an UPDATING file in the ports tree but 
> that's more for portmaster and portupgrade users.
First of all, synth ignores /etc/make.conf completely. Yes, we 
definitely need another place to keep global make options, however 
DEFAULT_VERSIONS suggestion is a bad advice here.
Here is example: recently ports framework deprecated perl 5.20 and 
switched to 5.24
portmaster users should recompile all ports depended on perl (from my 
point of view this is done not very reliable), but when it comes to new 
perl, portmaster will invoke dialog4ports.
synth user with non-default perl options will receive new perl with 
default one. I hit this very problem during my synth test when I noticed 
pgadmin3 liked to postgresql93-client and added DEFAULT_VERSIONS to 96.

>
>> So, synth is just a dumb port building tool. If you need your own port
>> options you are in risk. Developer of synth said that the problem is in
>> my 'portmaster thinking' I should change.
>
> An absurd assertion spoken loudly by someone that is ill-informed on 
> the topic.
I see how synth can be used in pkg framework, I even agree that synth is 
poudriere done right and I feel I will use synth test feature for ports 
I maintain, what I fail to see, how I can use it to keep my laptop 
updated. I'm not asking for pony here, the examples I provided (if true) 
lead to overcomplexity maintaining packages up to date.