I prefer to use BSD libedit over GNU readline where possible. Building PostgreSQL with --with-libedit-preferred will build the `psql` command against libedit: awilcox on gwyn ~ % ldd /usr/bin/psql | grep libedit libedit.so.0 => /usr/lib/libedit.so.0 (0x3fffa7952000)
Note that when implementing this, the preferred semantics are to do it imagemagick-graphicsmagick, ffmpeg-libav, openssl-libressl etc style, so USE="readline libedit" would give you libedit, and USE=readline controls the functionality overall.
That isn't how most of the other ebuilds that I've been interacting with work. And in fact, I've done USE="-readline libedit" globally and the other packages in @world seem to work fine and do the right thing: [I] dev-lang/python Installed versions: 3.11.7(3.11)^t(03:21:59 02/21/24)(ensurepip gdbm libedit ncurses sqlite ssl verify-sig -bluetooth -build -debug -examples -pgo -readline -test -tk -valgrind) 3.12.1_p1(3.12)^t(03:23:35 02/21/24)(ensurepip gdbm libedit ncurses sqlite ssl verify-sig -bluetooth -build -debug -examples -pgo -readline -test -tk -valgrind) [I] dev-libs/libpcre2 Installed versions: 10.42-r1(0/3)(03:01:23 02/21/24)(bzip2 libedit pcre16 pcre32 split-usr unicode verify-sig zlib -jit -readline -static-libs -valgrind ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") Implementing it as USE="readline libedit" would certainly fix the ugliness introduced in my original MR, but it seems to me to violate POLA.
(In reply to A. Wilcox (awilfox) from comment #2) > That isn't how most of the other ebuilds that I've been interacting with > work. And in fact, I've done USE="-readline libedit" globally and the other > packages in @world seem to work fine and do the right thing: > > libedit is the only one of these which hasn't yet been migrated to the "provider" model. So, in that sense, one more badness isn't such a bad thing. I've been trying to fix it when I spot it but I haven't gone around doing a big migration yet either :(
(In reply to Sam James from comment #3) > libedit is the only one of these which hasn't yet been migrated to the > "provider" model. So, in that sense, one more badness isn't such a bad thing. > > I've been trying to fix it when I spot it but I haven't gone around doing a > big migration yet either :( Your "fix" is my "break". It's entirely possible to use a Gentoo system without sys-libs/readline installed at all, since app-shells/bash has its own copy if you USE=-readline, which is used in early stages as well. That's only possible because I can USE=-readline globally. It's going to be a mess for me to try and do a global USE="readline libedit" then manually -readline in package.use for each one that doesn't support libedit. Perhaps there could be an app-alternatives/readline for apps that don't care, and have the USE sit there. I'd still have to manually -readline, but at least I wouldn't have to set USE=readline globally to get libedit support at all. I could mostly rely on package defaults to DTRT. I actually don't know how this would work with PostgreSQL here, either. If USE=readline is required to USE=libedit, and readline? ( sys-libs/readline ), how would I avoid pulling in the (useless) readline dep to have libedit?
(In reply to A. Wilcox (awilfox) from comment #4) > (In reply to Sam James from comment #3) > > libedit is the only one of these which hasn't yet been migrated to the > > "provider" model. So, in that sense, one more badness isn't such a bad thing. > > > > I've been trying to fix it when I spot it but I haven't gone around doing a > > big migration yet either :( > > Your "fix" is my "break". It's entirely possible to use a Gentoo system > without sys-libs/readline installed at all, since app-shells/bash has its > own copy if you USE=-readline, which is used in early stages as well. > That's only possible because I can USE=-readline globally. > The idea is you'd try to do it all at once and then you get consistent behaviour where USE=readline lets you get the functionality and USE=libedit lets you control the provider. Specifying "I want readline functionality but only with libedit" is just one of those things we've accepted isn't really possible with the provider model and it mostly works out fine (better than before, anyway).
(especially given for that latter case, you can just mask readline and get a nice error for it, bosh)
