Re: mktool support for fetch

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%NetBSD.org@localhost> writes:

> On Wed, Oct 02, 2024 at 12:18:24PM +0000, nia wrote:
>> On Tue, Oct 01, 2024 at 01:15:45PM -0400, Greg Troxel wrote:
>> > I'm still opposed; it feels like we are headed for a one-way trip into
>> > "if your platform doesn't support rust, you can't develop for pkgsrc".
>> > I know that's not the intent, but so many things have ended up that way,
>> > and I am not able to come up with any 'rust optional' things that haven't.
>> > 
>> > I realize I'm an outlier here, but just for the record since the
>> > question was re-asked.
>> 
>> Right. This starts out as "a few packages have 10000 distfiles, must
>> write solution"
>
> We still need a solution for that, independent of the mktool patch.
>
>> and ends at "portable parts of pkgsrc rot because none
>> of the main developers actually test them".
>
> Noted. We don't want that.
>
> But isn't the alternative that whoever those developers are just carry
> around a patch in their checkouts? How is that an improvement?

It's a group decision that nonportable solution are not acceptable, and
it is a greater deviation from portable practice, compared to just
setting a variable.  But really the big point is to declare that pkgsrc
infrastructure has to be portable.

(There is also pkglint, but it seems that runs most places, rather than
only on a restricted set.  I'm ok with things that work except on vax,
for instance.  go has a much better track record of being widely
available without grief.  But I'm not sure it's really portable enough.)