Re: removing libreadline from base system
On Thu, Dec 01, 2011 at 08:41:12PM -0600, Brooks Davis wrote: On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. Agreed and known. If the application(s) using libreadline weren't already GPL I wouldn't have spoken up. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses to libedit. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. I guess this is the real agenda? To get ports to depend on an /usr/ports' version of libreadline? If so, can it please wait 6 months until we've gotten thru the current nightmare that /usr/ports is on FreeBSD-CURRENT? Until this November that most ports would not build on -current, one still cannot 'pkg_add -r' anything, etc... Right now, I don't think we need another thing different between FreeBSD pre-10 and 10 that will be a /usr/ports headache. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 3:17 PM, David O'Brien obr...@freebsd.org wrote: Agreed and known. If the application(s) using libreadline weren't already GPL I wouldn't have spoken up. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses to libedit. Nope. You forgot heimdal stuff. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. I guess this is the real agenda? To get ports to depend on an /usr/ports' version of libreadline? Agenda is available here: http://wiki.freebsd.org/GPLinBase If so, can it please wait 6 months until we've gotten thru the current nightmare that /usr/ports is on FreeBSD-CURRENT? Until this November that most ports would not build on -current, one still cannot 'pkg_add -r' anything, etc... Right now, I don't think we need another thing different between FreeBSD pre-10 and 10 that will be a /usr/ports headache. I would let portmgr and others decide on how long will the transition take. There is a PR about libreadline removal from base. It is being worked on. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. Eh? Its the same definition has been for the past 17 years -- that which is in /usr/src. As long as there is a GPL consumer of libreadline in /usr/src, there is no benefit to kicking libreadline out of /usr/src. I understand the anti-GPL sentiment -- I've done my share over the years to help achieve a GPL-free FreeBSD. But until there is a debugger that is anywhere near as capable (and mature) as GDB, we'll have a few GPL bits in /usr/src. I see that as OK -- its is small and contained. Show me a non-GPL consumer of libreadline in /usr/src and I'll do everything I can to have it work with libedit. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses I knew of to libedit. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Please tell me what consumer of libintl or libglib2 we have in /usr/src. Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? You're now being quite ridiculous. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 3:43 PM, David O'Brien obr...@freebsd.org wrote: On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. Eh? Its the same definition has been for the past 17 years -- that which is in /usr/src. As long as there is a GPL consumer of libreadline in /usr/src, there is no benefit to kicking libreadline out of /usr/src. I understand the anti-GPL sentiment -- I've done my share over the years to help achieve a GPL-free FreeBSD. But until there is a debugger that is anywhere near as capable (and mature) as GDB, we'll have a few GPL bits in /usr/src. I see that as OK -- its is small and contained. One of the suggested alternatives (that looks more viable to me now because of incompatibilities between libedit and libreadline) is to have libreadline as INTERNALLIB. So that it is not exposed outside of gdb build. So that if we ever decide to replace gdb with something else in the base all we have to do is to svn rm gdb and friends. In other words, I suggest to reduce the number of dependencies on base system libreadline to just base system gdb. E.g. we do not expose expat from our base system to the outside world because we do not want to have unnecessary dependencies between base and ports. Show me a non-GPL consumer of libreadline in /usr/src and I'll do everything I can to have it work with libedit. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses I knew of to libedit. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Please tell me what consumer of libintl or libglib2 we have in /usr/src. Your sentiment was about having libreadline port/package to be installed on almost every system. We already have such packages (libintl and libglib2) so there is nothing wrong with having libreadline as a port/package and it does not imply that we should have it installed with the base system. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. Again, what problem are you trying to solve? The question is what to do with gdb friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Consider this an explicit request to do nothing to the base libreadline. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. I'm inclined to DO NOTHING. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. The existence of incompatibilities between libedit and libreadline probably does argue for option (2). -- Brooks pgpNBlLgOGQcg.pgp Description: PGP signature
Re: removing libreadline from base system
Brooks, On Fri, Dec 2, 2011 at 9:41 AM, Brooks Davis bro...@freebsd.org wrote: What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. The existence of incompatibilities between libedit and libreadline probably does argue for option (2). Agree. I submitted the patch w/ INTERNALLIB for libreadline for 10.0 exp-run. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:59 AM, David O'Brien obr...@freebsd.org wrote: This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. What I meant is that this problem is not related to the original question but it will be analyzed/resolved before the commit (if it will ever happen). I am not saying that my sole intention is to remove libreadline from base system. I just picked an item from here http://wiki.freebsd.org/GPLinBase and will come up with the analysis. If it turns out that libreadline removal is impractical it will not be removed. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: Hello! It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Max Back when I sent a libedit upgrade patch, before obrien update libedit on his own, I managed to build the whole tree with libedit, gdb, ntpc and others were fully functionnal with it, (at that time I totally removed libreadline) The only problem I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully dropped libreadline. regards, Bapt pgpOvhVpiD28u.pgp Description: PGP signature
Re: removing libreadline from base system
Baptiste, On Tue, Nov 29, 2011 at 3:59 PM, Baptiste Daroussin b...@freebsd.orgwrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Back when I sent a libedit upgrade patch, before obrien update libedit on his own, I managed to build the whole tree with libedit, gdb, ntpc and others were fully functionnal with it, (at that time I totally removed libreadline) The whole src tree now builds without libreadline. The only problem I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully dropped libreadline. This is a separate issue that I want to handle separately. The question is what to do with gdb friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: Baptiste, On Tue, Nov 29, 2011 at 3:59 PM, Baptiste Daroussin b...@freebsd.orgwrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Back when I sent a libedit upgrade patch, before obrien update libedit on his own, I managed to build the whole tree with libedit, gdb, ntpc and others were fully functionnal with it, (at that time I totally removed libreadline) The whole src tree now builds without libreadline. The only problem I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully dropped libreadline. This is a separate issue that I want to handle separately. The question is what to do with gdb friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Max linking to libedit is the right way imho. regards, Bapt pgp7Ci4jZsOyn.pgp Description: PGP signature
Re: removing libreadline from base system
The only problem I see is from the ports lots of them relies on base libreadline, so we need to first run an exp-run without libreadline, to determine the impact and fix the related ports, before we can fully drop libreadline. One of the first port to consider, i think, is rlwrap. Some time ago i had to compile it on a mac (which is equipped with libedit in place of libreadline) and it had problems since it calls functions in libreadline not in libedit . So i was forced to also compile libreadline. -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
removing libreadline from base system
Hello! It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
