Menu
▾
▴
bashdb-devel
|
From: R. B. <ro...@pa...> - 2003-08-11 11:00:10
|
Folks: At my urging, Matthias Klose, a Debian bash maintainer, has been looking at making this project industrial-strength enough for Debian inclusion. As a result, there has been a flurry of activity since the 0.41 release. The presumption is that a number of configuration and build bugs have recently been (or will be) fixed. A stumbling block that most people run into in trying to make a distribution release is that the this project doesn't build outside of the source tree. A number of changes in CVS are related to that. Another common comment is that the debugger include files (which I had thought of as analogous to a script library) currently install somewhere under "lib", whereas I'm told a more natural convention is to install under "share." The current configurability of making this change is lacking at least in the bashdb script if not also the bash program and probably inside the configuration system as well. Mikael Andersson who expressed a desire to make gentoo distribution, noted, and I believe he's done some work towards addressing this in the code. Something else I guess I will address sooner than later is the lack of a manual page. Right now my plan is to write one in perlpod (rather than troff). A suggestion was use texi2pod and then pod2man, but I'd rather just write in perlpod and skip the texi2pod step. If someone has another tool or suggestion, let me know. Matthias Klose also mentioned a possible deficiency in using the GNU Free Documentation License (GFDL) for the bashdb manual this link http://home.twcny.rr.com/nerode/neroden/fdl.html suggests that GPL is a better thing to use. Anyone know anything about this? Finally, the question has arisen here and elsewhere as to what to call the bash-2.05b executable that has been modified to improve error reporting and debugging support (and also now timestamps the history file which I think essential if you use bash as your root shell). I suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb since there already is a bash-minimal and a bash-static in Debian. Going in a completely different direction, some friends have been urging me to call the project "rebash." I think this is a catchy name. After all, "bash" is the "Bourne-Again Shell" so this is the "ReBourne-Again shell." Also sounds like "Rebok" and just the name "rebash" is appropriate for the same reason that "bash" was a bash of "sh". As always, I solicit comments and thoughts of any of the matters above. Thanks. |
|
From: Mikael A. <sn...@te...> - 2003-08-12 10:42:05
|
On Monday 11 August 2003 12.59, R. Bernstein wrote: > Folks: > > At my urging, Matthias Klose, a Debian bash maintainer, has been > looking at making this project industrial-strength enough for Debian > inclusion. As a result, there has been a flurry of activity since the > 0.41 release. The presumption is that a number of configuration and > build bugs have recently been (or will be) fixed. > > A stumbling block that most people run into in trying to make a > distribution release is that the this project doesn't build outside of > the source tree. A number of changes in CVS are related to that. > I'm curious about the $ac_prefix variable that is beeing used. I can't find where it's defined or what it's supposed to mean. > Another common comment is that the debugger include files (which I had > thought of as analogous to a script library) currently install > somewhere under "lib", whereas I'm told a more natural convention is > to install under "share." The current configurability of making this > change is lacking at least in the bashdb script if not also the bash > program and probably inside the configuration system as well. > > Mikael Andersson who expressed a desire to make gentoo distribution, > noted, and I believe he's done some work towards addressing this in > the code. This is correct. I'm almost done with this now i belive, although there are a few things with Matthias changes i don't fully understand ( the origin of ac_prefix beeing the 'showstopper' for me ). > > Something else I guess I will address sooner than later is the lack of > a manual page. Right now my plan is to write one in perlpod (rather > than troff). A suggestion was use texi2pod and then pod2man, but I'd > rather just write in perlpod and skip the texi2pod step. If someone > has another tool or suggestion, let me know. > > Matthias Klose also mentioned a possible deficiency in using the GNU > Free Documentation License (GFDL) for the bashdb manual this link > http://home.twcny.rr.com/nerode/neroden/fdl.html > suggests that GPL is a better thing to use. Anyone know anything about > this? <warning licensing comments and opinions ahead, DON'T PANIC!> There could be issues with this, albeit the problem of being unable to extract text between source and documentation seems vague since quoting of text in 3rd-party manuals must have been done for years and being established as fair use. It can't be automated though, but i don't know if thats' an important issue. The translation requirements are a bit extreme though. If someone purposefully retranslates a invariant section erroneously i don't think they'll care to include the english version even if the license mandates it. And for all other situations having english text in a translated document is strictly a nuisance. The issues about a refernce-card having to carry it's own copyright could actually be considered to be the case with GPL-2 also. Since any modified copy (sect 2 in GPL) is governed by section 1 which demands that "... in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program." And as a reference card would be a modification ( a subset, not the entire program ) it too should have to carry it's own license under the GPL. So if you plan to make truckloads of reference-cards to distribute to the world i suggest you include a licence flyer GFDL or GPL alike ;) The invariant section isn't that controversial in my view. If the document creator has any non-technical (ie no on the topic), maybe ideological standpoints that he/she feel important to attach to the documentation. Other people shouldn't be allowed to remove/alter these sections. This is one of the reasons why the GPL also states that all changes must be prominently marked as such in the files. My personal view is that either GPL or GFDL is workable but as noted by fsf (http://www.gnu.org/licenses/fdl.html#SEC4) "If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.". The difference with GFDL (from GPL) is that: "The GNU Free Documentation License is a form of copyleft intended for use on a manual, textbook or other document to assure everyone the effective freedom to copy and redistribute it, with or without modifications, either commercially or noncommercially." That is: It's intended for both non-commercial _and_ commercial use and thus have a slightly different scope. If you want people to be able to publish a commercial book based on bashdb manuals you could probably release it under GPL + GFPL, selectable at the users discretion. This would (IANAL) lead to that all non-commercial publisher/distributors would be free to choose GPL or GFPL but that a commercial publisher would be forced to use GFPL and as such preserve all invariant sections. Effectively it should allow a joint development of a document, including it's invariant sections (as we choose GPL when doing whis work). If you choose this i belive you should get a second opinion on it, either from lic...@op... or from anyone more familiar with licensing than me. Albeit GFDL isn't on their list of approved licenses it's not unlikely that they can give a more clearcut reasoning as why to select either license than i can. > > Finally, the question has arisen here and elsewhere as to what to call > the bash-2.05b executable that has been modified to improve error > reporting and debugging support (and also now timestamps the history > file which I think essential if you use bash as your root shell). I > suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb > since there already is a bash-minimal and a bash-static in > Debian. Going in a completely different direction, some friends have > been urging me to call the project "rebash." I think this is a catchy > name. After all, "bash" is the "Bourne-Again Shell" so this is the > "ReBourne-Again shell." Also sounds like "Rebok" and just the name > "rebash" is appropriate for the same reason that "bash" was a bash of > "sh". I think bash+dbg is good with the current scope of the project, but rebash if we intend on reviving bash development a bit when we're at it :). > > As always, I solicit comments and thoughts of any of the matters > above. > > Thanks. > /Mikael |
|
From: R. B. <ro...@pa...> - 2003-08-12 12:02:34
|
Mikael Andersson asks: > I'm curious about the $ac_prefix variable that is beeing used. I can't find > where it's defined or what it's supposed to mean. I looked again too. Generally things that start $ac_ are autoconf things. $ac_default_prefix was the default prefix used and probably the problem was that if you set this to something else that wasn't respected. I think the right variable then is $prefix (without the ac_). and opines: > <warning licensing comments and opinions ahead, DON'T PANIC!> No panic, just the contrary. I appreciate you taking the time give a thoughtful reply. I need to study what you've written and the issue itself in more detail. I am also seeking the advise and wisdom of those I respect in such matters. > I think bash+dbg is good with the current scope of the project, but rebash if > we intend on reviving bash development a bit when we're at it :). Bash development has always been rather slow because basically it's been a closed system and as far as I can tell there's only one person who dictates what goes in. Contrast this with say Perl developement where you have maybe 10 or so "core" developers and 100s of module developers. (And Perl is not atypical, the GNU/Linux kernel, gcc, apache, or php are about the same.) I started this project in the hope that others would get interested in aspects that others feel need improving and could contribute. Initially the thing that irked me the most was the lack of debugging support which has been in Perl over a decade, and a lack of timestamped history which I've been using a decade or more in tcsh. In this respect, I would prefer "rebash". |
|
From: Masatake Y. <je...@gy...> - 2003-08-14 02:55:54
|
Some part of bashdb code has been merged into bash already? Not yet? Should I push again? Masatake |
|
From: Matthias K. <do...@cs...> - 2003-08-15 15:48:18
|
Mikael Andersson writes: > > Matthias Klose also mentioned a possible deficiency in using the GNU > > Free Documentation License (GFDL) for the bashdb manual this link > > http://home.twcny.rr.com/nerode/neroden/fdl.html > > suggests that GPL is a better thing to use. Anyone know anything about > > this? > > <warning licensing comments and opinions ahead, DON'T PANIC!> [thanks for your informative followup] I actually proposed to relicense or dual license the docs. The latter would have the advantage, that it could be merged back to the bash docs which have the same license for the docs (GPL) > > Finally, the question has arisen here and elsewhere as to what to call > > the bash-2.05b executable that has been modified to improve error > > reporting and debugging support (and also now timestamps the history > > file which I think essential if you use bash as your root shell). I > > suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb > > since there already is a bash-minimal and a bash-static in > > Debian. Going in a completely different direction, some friends have > > been urging me to call the project "rebash." I think this is a catchy > > name. After all, "bash" is the "Bourne-Again Shell" so this is the > > "ReBourne-Again shell." Also sounds like "Rebok" and just the name > > "rebash" is appropriate for the same reason that "bash" was a bash of > > "sh". > I think bash+dbg is good with the current scope of the project, but > rebash if we intend on reviving bash development a bit when we're at > it :). ok, I'll name it bash+dbg as well. Matthias |
|
From: R. B. <ro...@pa...> - 2003-08-16 03:48:03
|
Matthias Klose writes: > I actually proposed to relicense or dual license the docs. The latter > would have the advantage, that it could be merged back to the bash > docs which have the same license for the docs (GPL) I've solicited the help of someone more competent at this than I. If there are no "Invariant Sections" then GDFL is the same as GPL. Does Debain have a problem with documents that are GDFL that don't have any invariant sections? The only invariant section I see is in the current bashdb reference manual is what I would call FSF boilerplate in the info documentation: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``Free Software'' and ``Free Software Needs Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. (a) The Free Software Foundation's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.'' I'm trying to understand the objection is to this. There is a saying that "the freedom for you to wave your fist ends at the tip of my nose". With freedom comes responsibility. People are free and welcome to make technical improvements or even make it technically worse. However the philosophical stuff they are not free to change at present. |
|
From: Matthias K. <do...@cs...> - 2003-08-16 06:46:10
|
R. Bernstein writes: > Matthias Klose writes: > > I actually proposed to relicense or dual license the docs. The latter > > would have the advantage, that it could be merged back to the bash > > docs which have the same license for the docs (GPL) > > I've solicited the help of someone more competent at this than I. If > there are no "Invariant Sections" then GDFL is the same as GPL. Does > Debain have a problem with documents that are GDFL that don't have any > invariant sections? yes, this is certainly the important point. some Debian people even are unhappy wit the cover texts, but there's not yet a final statement/policy. |
|
From: James M. D. <mdu...@ya...> - 2003-08-16 13:43:29
|
--- "R. Bernstein" <ro...@pa...> wrote: > Matthias Klose writes: > > I actually proposed to relicense or dual license the docs. The > latter > > would have the advantage, that it could be merged back to the bash > > docs which have the same license for the docs (GPL) > > I've solicited the help of someone more competent at this than I. If > there are no "Invariant Sections" then GDFL is the same as GPL. Does > Debain have a problem with documents that are GDFL that don't have > any > invariant sections? > > The only invariant section I see is in the current bashdb reference > manual is what I would call FSF boilerplate in the info > documentation: > > Permission is granted to copy, distribute and/or modify this > document > under the terms of the GNU Free Documentation License, Version 1.1 > or > any later version published by the Free Software Foundation; with > the > Invariant Sections being ``Free Software'' and ``Free Software > Needs > Free Documentation'', with the Front-Cover Texts being ``A GNU > Manual,'' and with the Back-Cover Texts as in (a) below. > > (a) The Free Software Foundation's Back-Cover Text is: ``You have > freedom to copy and modify this GNU Manual, like GNU software. > Copies > published by the Free Software Foundation raise funds for GNU > development.'' > > I'm trying to understand the objection is to this. There is a saying > that "the freedom for you to wave your fist ends at the tip of my > nose". With freedom comes responsibility. People are free and welcome > to make technical improvements or even make it technically > worse. However the philosophical stuff they are not free to change at > present. Yes. What is the problem here. Just view the invariant sections as non-content. What if the document has %0 content? delete it. make a policy that it must contain %75 content or not be allowed in the distro. the FSEDu project puts all of its wiki under the GDFL. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X