Re: mktool support for fetch

[pin <voidpin%protonmail.com@localhost>]

-------- Ursprungligt meddelande --------
Den 2024-10-05 17:00, Greg Troxel <gdt%lexort.com@localhost> skrev:

>  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

Where is democracy when the majority votes yes and the result is still no?

This doesn't sound "correct". I fully understand your (and others) reasons but, if I still can count, most would like to have this. I would respekt if the majority said no but, this is not the case.

The rest is irrelevante.

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.)
>  
>