Re: mktool support for fetch

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

Thomas Klausner <wiz%gatalith.at@localhost> writes:

>> and "cargo install mktool" to install the latest client (0.1.11).
>
> I'm fine with adding the TOOL ifdefs to mk/, does anyone else see
> problems with that?

(PMC hat very very off!)

I have avoided writing this, but I don't think it's wise to add tools
that rely on rust to the pkgsrc infrastructure, at all.

I don't mean to comment on rust the language; that's not the point.

Rust has zero reasonable implementations.  It is limited on the
platforms where it runs.  Perhaps more importantly, it's been a constant
struggle -- with a huge amount of effort from multiple people -- to keep
it running on NetBSD.  It's hard to comprehend how anyone can see as
reasonable upstream's practice of requiring the immediately-previous
compiler version.  There is no plausible story for a "reduced binary
seed" build like the guix folks have been working on.  Perhaps more
importantly, there is only, so far, one implementation.  (That can be
ok, when it is more or less "builds anywhere, given C [with an 'except
VAX', I've become ok with]".)

Already, we have pkglint in go.  While I don't think that's a great
situation, go has a track record of being buildable most places without
drama.  I just built pkglint on a RPI3, and while I had to put WRKDIR
not in /tmp for go itself (for 3 of the 4 copies!), it otherwise merely
took multiple hours of waiting.  go used to seem more reasonable, when
go14 was buildable with C, and other go with 1.4.  Then you needed 1.18,
and apparently now 1.20 also.  I fear they are losing perspective.  But
still, there is a build that works, without downloading binaries.
(Without bsiegert@, I'm not sure where we'd be.)

I know this is said to be optional.  But I don't have confidence that it
will stay that way, and suspect we'll sooner or later get to "you just
need to use the rust version; your platform is deficient".  Avoiding
that will mean that we'll have to prohibit mktool from having features
not in the base pkgsrc/mk, being limited to faster implementations, with
the other ones still being usable.  That's how it has been framed, but I
am very skeptical that this will last.

Thus, I'm opposed.  I suspect that my view is somewhat of an outlier,
and I don't expect anybody to pay attention to it.  I'm just filing it
so that future self has a link to point to when we cross the line, and
I'll be happy not to want to use it, if it turns out that way.