portmaster, portupgrade, etc
list1 at gjunka.com
Thu Oct 5 20:24:14 UTC 2017
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
More information about the freebsd-ports