Re: Fwd: Re: libjpeg for debian, autoconf
--- Henning Makholm <henning@makholm.net> wrote:
> Scripsit Steve Langasek <vorlon@netexpress.net>
>
> > 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/
Reply to: