Hello Eric,
czw., 4 mar 2021 o 10:31 Eric Bollengier <e...@baculasystems.com>
napisał(a):
> > and the Debian is using readline only for Bacula:
>
> Debian folks had a long "battle" because readline was GPL and not
> compatible with non-pure-GPL software, something like that. I don't know
> what was the final result of this, but it's nice to be able to use a BSD
> version of the readline, they are compatible.
>
You should be right as I can find:
libreadline-dev/oldstable,now 7.0-3 amd64 [installed]
GNU readline and history libraries, development files
libreadline-gplv2-dev/oldstable 5.2+dfsg-3+b1 amd64
GNU readline and history libraries, development files
>
> Also, I now remember that on some system, they had multiple versions of
> readline (something like readline4, readline5 and readline6) at the same
> time. My guess is that all these versions were in different directories,
> probably include/readline5/, include/readline6, etc...
>
Unfortunate, no. There is a single libreadline-dev version allowed:
libreadline-gplv2-dev : Conflicts: libreadline-dev but 7.0-3 is to be
installed
Conflicts: libreadline6-dev
So it seems that no multiple development headers are supported here.
> I was developing on Debian mostly at that time, and it can be a pretty
> good explanation why the current system is like this. If tomorrow
> readline8 is not compatible with readline7, the same situation may
> happen again.
>
>
I do not understand it.
> > So, if we want to support Bacula with editline as the replacement for
> > readline then we should extend our detection code and add a proper
> > compilation option.
> > This is my humble opinion.
>
> The actual system supports editline, but without a specific detection
> code in the configure process.
>
>
I disagree. The current code is unable to properly use a properly installed
editline library without configure tricks. I call it no-support.
# dpkg -l|grep libedit
ii libedit-dev:amd64 3.1-20181209-1 amd64
BSD editline and history libraries (development files)
ii libedit2:amd64 3.1-20181209-1 amd64
BSD editline and history libraries
ii libeditline-dev 1.12-6.1 amd64
development files for libeditline
ii libeditline0 1.12-6.1 amd64
line editing library similar to readline
# grep READLINE src/config.h
/* #undef HAVE_READLINE */
/* #undef HAVE_READLINE */
BTW. I'm not sure why there are two HAVE_READLINE definitions in config.h?
> If you are sure that the editline library is a drop-in replacement to
> > readline then it is trivial to add this library detection and start to
> > support it officially.
>
> If users are using it and report an error or a patch, I think we would
> accept them, readline is part of the system, so, we have the right to
> link against it even if it's GPL.
>
In my opinion:
- any library external to the project should be used with #include <...>.
- readline library should be used with <readline/readline.h> etc. as this
is a proper way designed by readline developers
- the macro READLINE_LIBRARY should be removed as it is an
internal/unofficial api (for example, it is not used by editline anymore)
- editline library support should be added explicitly
- this all clean the code
I hope you agree.
--
Radosław Korzeniewski
rados...@korzeniewski.net
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
