Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 06:38:25AM +0400, Andrey A. Chernov wrote: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I don't, particularly since the two programs which use it are already GNU software, so you haven't actually bought any additional freedom by making such a change. A third is vinum, which buys some additional freedom :-) So lets use it for vinum only leaving gnu soft bug-to-bug compatible with itself. After re-reading this entire thread, I still agree with Andrey. But is there some reason you are holding back updating libedit for those programs that do use it today (or are non-GPVed and could use libedit)? The LukeM ftp client, needs the fuller NetBSD libedit, so it would be nice to get your patches committed to ours. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Fri, Jul 27, 2001 at 10:27:05AM -0700, David O'Brien wrote: On Tue, Jul 17, 2001 at 06:38:25AM +0400, Andrey A. Chernov wrote: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I don't, particularly since the two programs which use it are already GNU software, so you haven't actually bought any additional freedom by making such a change. A third is vinum, which buys some additional freedom :-) So lets use it for vinum only leaving gnu soft bug-to-bug compatible with itself. After re-reading this entire thread, I still agree with Andrey. But is there some reason you are holding back updating libedit for those programs that do use it today (or are non-GPVed and could use libedit)? The LukeM ftp client, needs the fuller NetBSD libedit, so it would be nice to get your patches committed to ours. I'm planning to commit it soon. Kris PGP signature
Re: libedit replacement for libreadline
Erik Trulsson wrote: Peter MFC'ed it a few weeks ago. A few days ago is more like it. (cvs log lib/libcrypto/Makefile gives the following:) revision 1.24.2.4 date: 2001/07/16 03:28:26; author: peter; state: Exp; lines: +11 -56 MFC: unify libscrypt/libdescrypt into libcrypt. Thanks; good to see that what I was seeing was true when I first responded in this thread, and that Peter was very conscientious in correcting the oversight. I think there are a number of ports libraries that do the same thing, however, so Garrance not withstanding, I still think it would be a good idea to follow the initial crypt example: use a symlink for libreadline, which can be optionally overridden by a user who wants to do it. I think there is real value in being able to use vinum tools in the absence of a mounted /usr, without causing vinum to be GPL'ed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Thu, Jul 19, 2001 at 12:24:07AM -0700, Terry Lambert wrote: I'm saying fix it both places, or it obviously is not a sufficient justification for a decision. Or to put it another way if you are willing to live with it in one place, why not two?. What on earth are you talking about? I guess I need to paint a picture... It points to a ...stripped down [libcrypt] under '[libcrypt]' that tries to pretend to be a full version (f.e for [passwd], etc.. I should think the analogy between doing for libreadline what FreeBSD _already does_ for libcrypt should be obvious, now... So if you aren't willing to fix libcrypt to be the real thing under FreeBSD, now that export restrictions have been relaxed, I don't think you have any right to complain when someone does _exactly the same thing_, making libreadline* a symlink to libedit*, since your unwillingness to fix the former makes doing that common, accepted practice. Okay, now I'm really confused. a) libcrypt has been reunified for 7 months now; Peter did it last December. b) Regardless, I'm the one who was talking about making libreadline a symlink to libedit, I wasn't arguing against it. Kris PGP signature
Re: libedit replacement for libreadline
Kris Kennaway wrote: a) libcrypt has been reunified for 7 months now; Peter did it last December. Someone needs to tell my newly installed 4.3 system this. 4.3-RELEASE _did_ come out after that, right? I guess this wasn't MFC'ed? It seems to _still_ not have been MFC'ed in my 4.3-STABLE (pre-4.4) branch, so I'm guessing my example will remain true for 4.4-RELEASE and 4.5-RELEASE, as well, unless someone does something about it before then... b) Regardless, I'm the one who was talking about making libreadline a symlink to libedit, I wasn't arguing against it. Yes; I was just saying that (1) there's precedent, and (2) if someone doesn't agree with the validity of the precedent, then they better be prepared to invalidate it by doing all the needed work to make it invalid: deleting all traces of it, and anything like it, from the source tree. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote: Kris Kennaway wrote: a) libcrypt has been reunified for 7 months now; Peter did it last December. Someone needs to tell my newly installed 4.3 system this. 4.3-RELEASE _did_ come out after that, right? I guess this wasn't MFC'ed? It seems to _still_ not have been MFC'ed in my 4.3-STABLE (pre-4.4) branch, so I'm guessing my example will remain true for 4.4-RELEASE and 4.5-RELEASE, as well, unless someone does something about it before then... Peter MFC'ed it a few weeks ago. Kris PGP signature
Re: libedit replacement for libreadline
On Thu, Jul 19, 2001 at 02:01:31AM -0700, Kris Kennaway wrote: On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote: Kris Kennaway wrote: a) libcrypt has been reunified for 7 months now; Peter did it last December. Someone needs to tell my newly installed 4.3 system this. 4.3-RELEASE _did_ come out after that, right? I guess this wasn't MFC'ed? It seems to _still_ not have been MFC'ed in my 4.3-STABLE (pre-4.4) branch, so I'm guessing my example will remain true for 4.4-RELEASE and 4.5-RELEASE, as well, unless someone does something about it before then... Peter MFC'ed it a few weeks ago. A few days ago is more like it. (cvs log lib/libcrypto/Makefile gives the following:) revision 1.24.2.4 date: 2001/07/16 03:28:26; author: peter; state: Exp; lines: +11 -56 MFC: unify libscrypt/libdescrypt into libcrypt. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
At 12:24 AM -0700 7/19/01, Terry Lambert wrote: I guess I need to paint a picture... I guess we need to just ignore you on this particular topic. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
Kris Kennaway wrote: I vote this too. We don't need stripped down libreadline under 'libreadline' name pretend to be full version (f.e. for autoconf, etc.) [ ... remember this sentence; it answers your question ... ] I'm saying fix it both places, or it obviously is not a sufficient justification for a decision. Or to put it another way if you are willing to live with it in one place, why not two?. What on earth are you talking about? I guess I need to paint a picture... The libcrypt* in /usr/lib is a symlink. It points to a ...stripped down [libcrypt] under '[libcrypt]' that tries to pretend to be a full version (f.e for [passwd], etc.. I should think the analogy between doing for libreadline what FreeBSD _already does_ for libcrypt should be obvious, now... So if you aren't willing to fix libcrypt to be the real thing under FreeBSD, now that export restrictions have been relaxed, I don't think you have any right to complain when someone does _exactly the same thing_, making libreadline* a symlink to libedit*, since your unwillingness to fix the former makes doing that common, accepted practice. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
Andrey A. Chernov wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
The cryptography libraries have set a precedent here. I
could argue the same thing about the presence of a full DES
in libcrypt.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
Terry Lambert wrote:
Andrey A. Chernov wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
The cryptography libraries have set a precedent here. I
could argue the same thing about the presence of a full DES
in libcrypt.
I failed to understand what you are trying to say. Do you mean that we have
to follow a bad practice set by that precedent at any costs, or I parsed your
message incorrectly?
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
Maxim Sobolev wrote: I vote this too. We don't need stripped down libreadline under 'libreadline' name pretend to be full version (f.e. for autoconf, etc.) The cryptography libraries have set a precedent here. I could argue the same thing about the presence of a full DES in libcrypt. I failed to understand what you are trying to say. Do you mean that we have to follow a bad practice set by that precedent at any costs, or I parsed your message incorrectly? I'm saying fix it both places, or it obviously is not a sufficient justification for a decision. Or to put it another way if you are willing to live with it in one place, why not two?. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
hi, there! On Tue, 17 Jul 2001, Garance A Drosihn wrote: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. I read on pgsql-hackers mailinglist that only static linking with libreadline will infect your binaries with GPL virus. btw PostgreSQL already has support for NetBSD's libedit /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 10:27:14 -0700, Kris Kennaway wrote:
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
--
Andrey A. Chernov
http://ache.pp.ru/
PGP signature
Re: libedit replacement for libreadline
At 3:19 AM -0700 7/16/01, Kris Kennaway wrote: Hmm. We could easily provide a libreadline port for ports to use, as long as libedit does everything that's needed for the in-tree users (are there any others apart from bc and gdb?) The only danger is if future versions of those grow the need to use other parts of the API which we don't implement. The upside is that both the FreeBSD and NetBSD communities would be facing the same problem, meaning greater developer power to implement new features. Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. Is there some way freebsd could switch base-system components to use libedit, and then turn libreadline into a port for any other ports which need libreadline? And maybe have the README for the libreadline port just suggest to people that they might want to try libedit instead of installing the libreadline port? Note that part of what I want is for people who are looking for libreadline to find out that libedit exists. I'm not sure of the best way to do that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 12:23:28PM -0400, Garance A Drosihn wrote: I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. Is there some way freebsd could switch base-system components to use libedit, and then turn libreadline into a port for any other ports which need libreadline? I think hacking gdb to use libedit would cause a lot of pain for future maintenance, although bc allegedly supports libedit already (I say allegedly because last time I tried to build with it, it didn't compile). Vinum is the third thing in the base system which uses libreadline: it could feasibly be rewritten. However, gdb, vinum and bc all compile fine using the libreadline API shim for libedit (modulo bugs and missing features which people need to investigate and tell me about), leaving no dependencies on GNU libreadline in the base system at the present time. Kris PGP signature
Re: libedit replacement for libreadline
On Wed, 18 Jul 2001 00:23:43 +0400, Andrey A. Chernov wrote:
On Tue, Jul 17, 2001 at 10:27:14 -0700, Kris Kennaway wrote:
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
This idea was certainly crossing my mind too. This way we would insure
ourserves from a number of weird problems associated with having two
version of libreadline.{a,so} and appropriate similarly named headers
in /usr and /usr/local. Ports that can work with libeditNG then could
be properly tailored to link with it instead of GNU libreadline. The
only drawback here is that authors of tools, which need to be linkable
with both libeditNG and GNU libreadline (think about vinum) will have to
do some black #ifdef magick, but that's life...
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
At 9:40 AM -0700 7/17/01, Kris Kennaway wrote:
On Tue, Jul 17, 2001, Garance A Drosihn wrote:
Is there some way freebsd could switch base-system components to
use libedit, and then turn libreadline into a port for any other
ports which need libreadline?
I think hacking gdb to use libedit would cause a lot of pain for
future maintenance, although bc allegedly supports libedit already (I
say allegedly because last time I tried to build with it, it didn't
compile). Vinum is the third thing in the base system which uses
libreadline: it could feasibly be rewritten.
However, gdb, vinum and bc all compile fine using the libreadline API
shim for libedit (modulo bugs and missing features which people need
to investigate and tell me about), leaving no dependencies on GNU
libreadline in the base system at the present time.
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
I'm just wanted to suggest a few alternatives. I am a little uneasy
about just-replacing-libreadline, unless we have something which does
replace all of libreadline. My understanding of this libedit-shim is
that it isn't quite a complete replacement. I think we'd want to be
able to switch a component between the real libreadline and this
libedit-shim version. The base system would not include libreadline,
but if someone added it from ports then they wouldn't have to worry
about the real-version changing how the system-components worked.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
Kris
PGP signature
libedit replacement for libreadline
Hi all, I've just finished syncing up our libedit to the version in NetBSD, which includes a number of bugfixes, but perhaps more interestingly it can function as a drop-in (apparently binary compatible) replacement for GNU libreadline (unfortunately it's not binary compatible with our present libedit). I've tested this so far with bc and gdb and it seems to indeed work as expected, though I've not yet done a full make world with the patches. I've tried not to spam any previous FreeBSD changes (which should probably be submitted back to NetBSD to keep us fully in sync), but I may have missed something and will check again later. I've CC'ed the FreeBSD people who have made most of the (few) changes to libedit on our side in case they have time to verify the diffs. Fetch the following file and unpack it in /usr/src; it will overwrite the contents of lib/libedit. You should also disable libreadline in gnu/lib/Makefile (and might want to remove /usr/include/readline/* to make sure it picks up the new versions). http://www.freebsd.org/~kris/libedit.tgz Comments welcome. Kris PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 01:31:27AM -0700, Kris Kennaway wrote: I've just finished syncing up our libedit to the version in NetBSD, which includes a number of bugfixes, but perhaps more interestingly it can function as a drop-in (apparently binary compatible) replacement for GNU libreadline (unfortunately it's not binary compatible with our present libedit). It doesn't actually impliment all of libreadline - just it's most common uses. Last time I checked libedit couldn't emulate readline's callback mode. I looked at implimenting the callback stuff, but it would be really hard to do properly 'cos of how libedit is structured. (In the end I hacked something together, but it's really ugly.) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 01:31:27AM -0700, Kris Kennaway wrote: for GNU libreadline (unfortunately it's not binary compatible with our present libedit). I've tested this so far with bc and gdb and it ..or source compatible, apparently. I thought I'd tested this with the ftp client, but I must have been using old headers or something. I'll have to look at this some more. Kris PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 10:33:51AM +0100, David Malone wrote: On Mon, Jul 16, 2001 at 01:31:27AM -0700, Kris Kennaway wrote: I've just finished syncing up our libedit to the version in NetBSD, which includes a number of bugfixes, but perhaps more interestingly it can function as a drop-in (apparently binary compatible) replacement for GNU libreadline (unfortunately it's not binary compatible with our present libedit). It doesn't actually impliment all of libreadline - just it's most common uses. Last time I checked libedit couldn't emulate readline's callback mode. I looked at implimenting the callback stuff, but it would be really hard to do properly 'cos of how libedit is structured. (In the end I hacked something together, but it's really ugly.) Hmm. We could easily provide a libreadline port for ports to use, as long as libedit does everything that's needed for the in-tree users (are there any others apart from bc and gdb?) The only danger is if future versions of those grow the need to use other parts of the API which we don't implement. The upside is that both the FreeBSD and NetBSD communities would be facing the same problem, meaning greater developer power to implement new features. Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. Kris PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 10:33:51 +0100, David Malone wrote: On Mon, Jul 16, 2001 at 01:31:27AM -0700, Kris Kennaway wrote: I've just finished syncing up our libedit to the version in NetBSD, which includes a number of bugfixes, but perhaps more interestingly it can function as a drop-in (apparently binary compatible) replacement for GNU libreadline (unfortunately it's not binary compatible with our present libedit). It doesn't actually impliment all of libreadline - just it's most common uses. Last time I checked libedit couldn't emulate readline's callback mode. I looked at implimenting the callback stuff, but it would be really hard to do properly 'cos of how libedit is structured. (In the end I hacked something together, but it's really ugly.) I don't think that libreadline replacement is good idea. Libreadline is moving target - every version adds new functions and renames old ones. I doubt that NetBSD people will follow libreadline closely. Moreover, I think some libreadline stuff is very libreadline specific and will be not implemened in any case. So libedit as libreadline replacement can be used only if you want to save some space on floppy for very simple libreadline application, but not in general case. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 02:33:00PM +0400, Andrey A. Chernov wrote: It doesn't actually impliment all of libreadline - just it's most common uses. Last time I checked libedit couldn't emulate readline's callback mode. I looked at implimenting the callback stuff, but it would be really hard to do properly 'cos of how libedit is structured. (In the end I hacked something together, but it's really ugly.) I don't think that libreadline replacement is good idea. Libreadline is moving target - every version adds new functions and renames old ones. I doubt that NetBSD people will follow libreadline closely. Moreover, I think some libreadline stuff is very libreadline specific and will be not implemened in any case. So libedit as libreadline replacement can be used only if you want to save some space on floppy for very simple libreadline application, but not in general case. Well, it depends on how you think of it; if you think of it instead as a minimal libreadline which does enough to support the other readline consumers in the FreeBSD base OS, then it makes a lot more sense to replace, IMO. We can make a port of GNU libreadline to satisfy ports which need more. Referring to Section 1.3.2 (FreeBSD Project Goals), this move seems to be well in line with the charter of the project. Kris PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 12:41:18 -0700, Kris Kennaway wrote: The vinum patch hilights the problem that the new libreadline (just a symlink to libedit) exposes new symbols which may conflict with an existing program. I'm not sure how to deal with this. Can of worms opened, as I warn you beforehead :-) -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 12:00:55 -0700, Kris Kennaway wrote: On Mon, Jul 16, 2001 at 11:16:12AM -0400, Garrett Wollman wrote: On Mon, 16 Jul 2001 03:19:32 -0700, Kris Kennaway [EMAIL PROTECTED] said: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I don't, particularly since the two programs which use it are already GNU software, so you haven't actually bought any additional freedom by making such a change. A third is vinum, which buys some additional freedom :-) So lets use it for vinum only leaving gnu soft bug-to-bug compatible with itself. -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
Re: libedit replacement for libreadline
On Mon, 16 Jul 2001 03:19:32 -0700, Kris Kennaway [EMAIL PROTECTED] said: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I don't, particularly since the two programs which use it are already GNU software, so you haven't actually bought any additional freedom by making such a change. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 11:16:12AM -0400, Garrett Wollman wrote: On Mon, 16 Jul 2001 03:19:32 -0700, Kris Kennaway [EMAIL PROTECTED] said: Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I don't, particularly since the two programs which use it are already GNU software, so you haven't actually bought any additional freedom by making such a change. A third is vinum, which buys some additional freedom :-) Kris PGP signature
Re: libedit replacement for libreadline
On Mon, Jul 16, 2001 at 01:31:27AM -0700, Kris Kennaway wrote: Fetch the following file and unpack it in /usr/src; it will overwrite the contents of lib/libedit. You should also disable libreadline in gnu/lib/Makefile (and might want to remove /usr/include/readline/* to make sure it picks up the new versions). http://www.freebsd.org/~kris/libedit.tgz I've updated this file with an improved makefile for libedit, as well as a patch which should allow world to build (the pppctl changes are from Brian, most of the rest are taken from or inspired by changes applied to NetBSD). The vinum patch hilights the problem that the new libreadline (just a symlink to libedit) exposes new symbols which may conflict with an existing program. I'm not sure how to deal with this. Kris PGP signature
