--- Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Steve Langasek <[EMAIL PROTECTED]> > > > The absence of the configure.in used to generate the present > > configure script is a bit of a nuisance, but I'm not sure it's > > substantial enough to regard this as not being DFSG-compliant. I'm > > sure other list subscribers will weigh in if they disagree with me > > on this point. > > I think that the configure.in is sufficiently important for further > development (and sufficiently nontrivial for mortals to reconstruct > from configure) that the spirit of the social contract and the DFSG > mandate that we distribute it as part of the source.
I volunteer to fix the problem if needed. The idea of reverse engineering the configure does not make me happy, but it should not take more than a couple of hours. > > However, unless we have solid evidence that the upstream author > specifically don't want to disclose their configure.in, we should > treat > it as a case of honest oversight and not start throwing legalese into > the battle immediately. Ok, I am too quick to shoot, I admit. I will await some guidance from you before futher action. >From my POV,even if it's license does require all sources to be there, as soon as we start using it in a GPL package (like GTK+, used by everyone) then it does matter for sheer numbers of GLPed users. Otherwise, I could just give this type of license to any tool, and wrap a gpl wrapper around it and ignore all policy whatsoever. I tend to view this as GPLified BSD-like code, and should be treated as if it GPL. For me it did not click immediatly, and I apologize for overreacting. The issue is that I am used to my rights as a receipient of GPL code, and of the high quality of the debian packages. That is why I chose to use the debian ports and porting system as a basis of a new GTK+ port to windows. So many peopl just distribute the dlls or the dll+libs, but not the >>sources<<. This leads to a stack of cards situation where only one person can build one dll, and no one can re-build all the dlls. by using the debian packaging system we can avoid this problem, each package can be "dpkg-built". I hope to include all the sources in my distribution, therefore it is important for at least me to include this pathetic configure.in. of course we might just assume that the users, not aware or caring of gnu issues or standard use, have just copied a configure file from a program that has all the options they need, and copied it into the distro. That might be the explaination of the problem. I have been working on a set of m4 macros that dump the name of the m4 source file and macro into the configure script for tracing, this with all major options configured in could be then diffed against the given configure file. That would highlight all of the areas where similar funtions were called. Otherwise a scanning of all the #ifdefs in the program and the removal of the configured headers (if any) would cause compiler errors tell us what m4 macros we have to aclocal into our programs configure.in. mike mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
