On Tue, Dec 14, 1999 at 01:28:21PM -0800, Darren wrote: > It's a good point. How should we rewrite section 4.2 to say that it > only refers to public libraries rather than internal libraries? And > which parts do and don't? What about compiled Perl modules, for > example? I don't know the answers to these questions.
A better question is: what's a library? When you're talking about traditional C programs, there's a clear distinction between executables, shared libraries, and other sorts of data. However, that's not so clear when talking about elisp, perl, or possibly anything else where someone has gone to a lot of work designing a different sort of infrastructure. [For example, java has its CLASSPATH which is independent of normal concepts of executables or shared libraries.] The simplest constraint on policy would be to label the shared library stuff as applicable to "traditional C programs" and leave it up to the maintainer and bug report filers whether the program has been classified properly. However, with some time and thought it might be possible to abstract out some underlying concepts which are more generally applicable. -- Raul
