Am Sun, 2 Mar 2025 14:14:59 +0000
schrieb Stuart Henderson <s...@spacehopper.org>:
> I do think we need to do _something_ with this, because as things
> stand, if an i386 user has fish as their shell, they will be left
> with old binaries which will stop working sometime. If not going for
> this approach then we'll need something in current.html / release
> notes so that people can change their user's shell in advance of
> upgrading.
I like the proposal splitting fish into v3 and v4. Within this week
I'll prepare a diff and send it to ports@.
Thanks again for the idea!
> On 2025/03/01 09:43, Stuart Henderson wrote:
> > On 2025/03/01 09:12, Theo Buehler wrote:
> > > On Sat, Mar 01, 2025 at 08:42:48AM +0100, Sebastien Marie wrote:
> > > > Stuart Henderson <s...@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.
> >
--
greetings,
Florian Viehweger
