On Wed Oct 21, 2026 at 16:56 CEST, Bjorn Ketelaars wrote:
> ipset crate was already needed for getting 2.5.1 to build:
>
> -MODCARGO_CRATES += ipset 0.9.0 # MIT
>
> This is because ipset is part of Cargo.lock, see the relevant Cargo.lock
> entry:
> https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2130-2140
>
> The reason for vendoring it now is that the current version requires a
> specific branch of the crate which isn't available through crates.io.
>
> The same applies to the jrsonnet* crates, for example these Cargo.lock
> entries:
> https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2530-2547
>
> So unless I'm overlooking something, I think the fact that ipset itself
> targets Linux is separate from why we need to vendor it here.
Yes, I understand that part, I'm just pointing out that in theory that
is the less important crate between itself and jsonnet lol, what I am
more curious about is from a ports infrastructure viewpoint: why do we
need to have a separate mirror of this stuff when it can presumably be
fetched at download time like all the normal crates, perhaps with some
DIST_TUPLE-like construct? Is it due to the branch switch?
>
> BTW, sysutils/reaction currently has no MAINTAINER. Would you be
> interested in taking it? If not, I’d be happy to pick it up.
I had already expressed interest in taking maintainer for this, yes,
especially considering I am in contact with upstream (Cced). However, I
must defer to your packaging expertise here, so if you don't mind me
bothering you in case something with this vendoring (or something
similar) comes up in later releases, I'll be happy to take maintainer :)
