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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
