Re: [Update] shells/fish 4.0.0

On 2025/03/01 09:12, Theo Buehler wrote:
> On Sat, Mar 01, 2025 at 08:42:48AM +0100, Sebastien Marie wrote:
> > Stuart Henderson <stu@spacehopper.org> writes:
> >
> > > On 2025/02/27 19:03, Volker Schlecht wrote:
> > >> MODULES = devel/cmake \
> > >> + devel/cargo \
> > >
> > > any idea if there are users of this on !rust archs?
> > >
> >
> > even if there are such users, upstream chooses this road so it is
> > preferable to copte with it. I am unsure it worths the pain to
> > maintaining both ports (like librsvg).
>
> I agree: shells/fish itself should follow upstream which has switched to
> rust.
>
> However, since this is a leaf port, we could reimport the old C++-based
> fish simply as shells/fish3 (there's perhaps a bit of pain for removing
> the conflict between the two versions if we want to do that).

I don't think it's necessary to avoid a conflict, the main reason for
doing that would be if other ports start to depend on fish (and even
that would be ok as long as they don't mind which version they have).

To handle updates nicely:

- change the path on both versions, for example shells/fish/v3 and
shells/fish/main

- have both use fish as the stem (fish-3.xx, fish-4.xx), like done in
Postfix

- use "@option is-branch" in both plists

- in v3, set a variable (e.g. RUST_COMMENT) to "@comment " on Rust
archs, and leave it empty on non-Rust archs, add it to SUBST_VARS, and
use "${RUST_COMMENT}@pkgpath shells/fish" in the plist

That way the package produced on non-rust archs will have the
annotation, and the v3 package on rust archs will have an @comment.

- in main, just have "@pkgpath shells/fish" in the PLIST (no need for
anything special there, as obviously it won't build on non-Rust archs
anyway)

This way, users with the existing package on a !rust arch will get
seamlessly adjusted to the new pkgpath for v3, users on a rust arch will
get moved to v4, and - importantly - there will only be one version on
an arch that has "@pkgpath shells/fish", so users on a rust arch won't
keep getting asked which version they want to update to when they run
pkg_add -u.

A user running "pkg_add fish" will be asked to choose which version, but
then updates will happen automatically. And for scripted installs,
"pkg_add fish%main" or "pkg_add fish%v3" will avoid it asking.

> My understanding is most of the pain of librsvg comes from it being an
> important dependency for graphics-based programs, so it has to be
> supported in the same port.

There is another way that could be done but would be messier in the
ports using librsvg; the same-port method means that the librsvg port is
a bit more complicated but other ports are simpler.