portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 18:41, Steve Kargl wrote:
> On Thu, Oct 05, 2017 at 10:52:51AM -0600, Adam Weinberger wrote:
>
> (courtesy long-line wrap)
>
>> You seem to be fully convinced in a conspiracy to destroy
>> portmaster, and I don't get the impression that I'm going
>> to change your mind. All I can tell you is that impending
>> portmaster breakage is NOT by design, and is only happening
>> because portmaster isn't actively developed anymore. If
>> you'd like to believe in secret poudriere cabals and
>> anti-portmaster conspiracies, that's up to you.
> Nope. No conspiracy theory here.  But, the above is a good
> method to deflect attention and blame.
>
> I simply find it ironic/comical that someone dreamt up
> flavours/subpackage for the ports collections with the
> knowledge that this will break all tools used to manage
> ports, and portmgr which is charged with
>
>     Discusses how that the way that the Ports Collection is
>     implemented affects the above policies, and, in particular,
>     such concepts as changes that require regression tests and
>     sweeping changes.
>
> (see https://www.freebsd.org/portmgr/) seems to have endorsed
> a "sweeping change" with this outcome.
>
> Then that someone managed to convince developers of a single
> ports management tool to implement support for flavours/subpackaged.
> So, portmgr now is going ahead with a "sweeping change" at the expense
> of all other ports management tool.  I have simply pointed out, portmgr
> and contributors to that single ports manange tool have a significant
> overlap.  Nope.  No conspiracy.  Just the truth.
>
> So, Adam, if the poudriere developers had stated that poudriere
> would not support flavors/subpackages would portmgr still wedge
> the necessary infrastructure into the Makefiles and *.mk files?
>

I don't understand this argument. Are flavours / subpackages good / 
desirable or they are not good / undesirable? As far as I know they 
enable features that otherwise wouldn't be possible. So surely not the 
later. So if the former, could they have been designed in a way that 
doesn't break existing build tools? Maybe yes, but if that was the case 
then surely someone would have proposed such a design? Or maybe even 
implemented it. Maybe at an additional cost of non-trivial changes 
somewhere else. Maybe updating the build tools was the easier option. In 
the end those are just build tools and no one should expect them to 
never change. But if that was the case, how would they go about updating 
ports to support new features? Of course, they would discuss with the 
maintainers of those tools, (why wouldn't they ?), if the change is 
feasible to implement in the tools and would take less effort than the 
mentioned change somewhere else instead. How many maintainers they would 
need to contact? I know of 4 - portmaster, portupgrade, synth and 
poudriere. Am I missing something? Oh, yes, the mighty make. But it will 
be mass-updated so no need to look for anyone. So, who should they 
contact to discuss the support for ports/subpackages in portmaster, 
portupgrade and synth? Should they hold off until a maintainer is found? 
Should they pay for updating these tools from their pocket (using their 
time)?

GrzegorzJ