Why both libedit and libreadline?

pypi · 2015-08-27 22:33:40

I'm lead to believe that libedit is a drop-in replacement for libreadline - although the internet appears to have differing opinions on that point - but both libedit and libreadline are packaged in Arch.

On my system:
- ntp depends on libedit.
- openssh depends on libedit (sftp links against it).
- some libraries in llvm-libs link against libedit.

However, *lots* of other things use libreadline instead!

There doesn't appear to be any discussions on the mailing lists about this.
Is anyone able to shed some light?

Thanks!

Trilby · 2015-08-27 22:38:44

What is it you want to know? There are libraries with overlapping purposes in the repos, yes. Just look at gtk and qt: why package both? Because some other packages use each of them.

Raynman · 2015-08-27 22:51:52

pypi wrote:

I'm lead to believe that libedit is a drop-in replacement for libreadline

What leads you to believe that? They seem to be quite different. Edit: I was looking at the editline man page, which says next to nothing about readline compatibility, but apparently it does exist (to some extent at least).

Last edited by Raynman (2015-08-28 10:49:50)

pypi · 2015-08-27 23:33:46

See sabotage's libedit package, for instance, and the musl-libc wiki page on alternative libraries.
I think that Mac OSX uses libedit instead of readline - as shown in the second answer to this stackoverflow question - but I'm not completely sure about that.

I guess there might be some licencing issues instead? http://thread.gmane.org/gmane.comp.db.p … ral/160471. And I'm assuming that libedit is indeed crippled in some way, but then why does OSX use it (apart from it being OSX)?

I'm thinking that perhaps anything that currently links against libedit could be made to link against libreadine, or vica-versa - reducing duplication would be good, right? But there's probably a reason why that hasn't happened. I'm curious...

Trilby · 2015-08-27 23:38:41

One could say much of the same about the various libc implementations.

But if having two alternatives bothers you, you could always come up with a single replacement for these two options.

pypi · 2015-08-27 23:49:40

Trilby wrote:

One could say much of the same about the various libc implementations.
But if having two alternatives bothers you, you could always come up with a single replacement for these two options.

Lots of other people have already done that...

pypi · 2015-08-28 00:28:03

Trilby wrote:

One could say much of the same about the various libc implementations.
But if having two alternatives bothers you, you could always come up with a single replacement for these two options.

More seriously though, Arch doesn't actually use two libc's (that's not quite true, but I'm not counting musl and dietlibc, since musl is only used for busybox, and I'm not sure why dietlibc is required at all, apart for interest purposes). I'm not sure why two seemingly compatiable bits of software would both be packaged - qt and gtk are quite different, agreed, but libedit seems to be aiming to be readline-compatiable. Unless, of course, libedit didn't have the required features or readline couldn't be linked to the other packages, I'm not quite sure why Arch would have both?
It would seem sensible if most systems would only end up using one or the other, but having both seems overkill. Busybox is different since it's specifically for embedded/rescue systems (although it appears that mkinitcpio-busybox links against glibc, not musl...), and nothing links against musl except for busybox.

I'm not particularily bothered by there being two choices, just curious as to why Arch packages them both, and doesn't consitently link against one or the other.

Lone_Wolf · 2015-08-28 10:36:39

Pypi,

Arch has a policy of keeping packages as 'vanilla' (close to upstream) as possible .

If an upstream author states readline as a dependency, so does arch.
same for libedit.

pypi · 2015-08-28 20:32:50

Lone_Wolf wrote:

Pypi,
Arch has a policy of keeping packages as 'vanilla' (close to upstream) as possible .
If an upstream author states readline as a dependency, so does arch.
same for libedit.

Right, thanks @Lone_Wolf. I guess it could extend as far as linking to the same pieces of code...

Arch Linux

#1 2015-08-27 22:33:40

Why both libedit and libreadline?

#2 2015-08-27 22:38:44

Re: Why both libedit and libreadline?

#3 2015-08-27 22:51:52

Re: Why both libedit and libreadline?

#4 2015-08-27 23:33:46

Re: Why both libedit and libreadline?

#5 2015-08-27 23:38:41

Re: Why both libedit and libreadline?

#6 2015-08-27 23:49:40

Re: Why both libedit and libreadline?

#7 2015-08-28 00:28:03

Re: Why both libedit and libreadline?

#8 2015-08-28 10:36:39

Re: Why both libedit and libreadline?

#9 2015-08-28 20:32:50

Re: Why both libedit and libreadline?

Board footer