[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Outdated GNU config (config.{sub,guess}) and autotools-dev



On Sat, Jul 21, 2001 at 09:21:18PM -0300, Henrique de Moraes Holschuh wrote:
> Note that only config.sub/guess was changed, AND that its source IS
> available  (in autotools-dev), and that we ALWAYS have that source available
> for download in our archives (or the autobuilder should not be using it).  I
> think it is rather doubtful that this would be considered a GPL violation,
> but that's something for debian-legal to decide.
>

Certainly.  Let me just say here that I don't think this is the definition of
availability that is expected by the GPL, section 3.
 
> > > Can be worked around: the more complicated script I suggest will tag the
> > > changelog properly. That information is NOT lost, as it makes to the
> > > .changes file, which is sent to the proper @list.debian.org ML, even if the
> > > autobuilder is not doing a source NMU.
> > 
> > Again, does only work if the files stay fixed atfer the source is generated.
> 
> No. This *always* work; One cannot upload something to debian without
> leaving tracks in the form of a .changes file, which should be ALWAYS
> archived (if it is not, we have something wrong...).   If one adds
> autotools-dev support that leaves no track on the changelog, it is his
> fault, not autotools-dev's.

The autobuilders are not supposed to make changes to the source, including
the changelog.  I didn't mean work in a technical way, more in a policy
compliant way (incl the license issue).

> You might need to ask me for a release of autotools-dev, [or I might simply
> export my CVS repository of autotools-dev to the Debian one] to retrieve an
> old version due to a binary NMU, but the source WILL be available.

This is certainly not the kind of availability that is defined by the GPL.
There are some explicit criterions in the GPL that, together with the
technical details of the makefile snippets, the behaviour of dpkg-buildpackage
and the Debian policy sum up to small violations here and there (like, the
small change to the source, or the modification of the changelog).

I am not saying that those problems are show stoppers for any possible
solution.  You have already pointed out a way which seems to be a good
compromise: A small addition to the interface which will automatize the
update at source but not at binary build time.

There might be other ways to comply with the GPL and Debian policy
(I could imagine that referring to the version of the files used
in the copyright file, and keeping all versions of autotool-dev in the
pool, might be such a way).

However, I don't think it is a good idea to rush over these details
and diminish them.  Changing the source at binary build time and
changing the Debian changelog at binary build time are both
suspicious things to do, and a careful inspection if there is a real need
and what other solutions there are, and how existing policies can be met,
is important, even if the actual effect of those operations is likely to
be small (after all, the quantity of a violation does not matter, and
it also sets a precedent).

> > Sounds like a good thing.  This target would be called by dpkg-buildpackage
> > if it is packaging the source package, but not when building a binary
> > package only.  Is this what you mean?  I would be happy with that.
> > It also leaves it open if we want autobuilders to run this target
> > or not:  We have the technical ability to do both, and can worry
> > about the way we use it just a teeny bit later (or do it differently
> > from package to package or port to port).
> > 
> > I would have absolutely no concern with that.  In fact, I would like it.
> 
> Please do note that if the autobuilders run it, it is no different than
> doing it in the clean target when it comes to what changes get lost in a
> binary-only NMU.

I know.  And I am still firm that the autobuilders should not run it.
It is just good if you can seperate a technical issue from a policy issue
in this way, as it makes you more flexible when it eventually comes to
making a decision.

> > Well, we don't really need a policy for that to do it that way.  As I see
> > it, the only change in your suggestion would be to remove the autotools
> > target from the clean targets dependencies.  The maintainer would then have
> 
> That would disable part of the automation autotools-dev can use to never
> require manual intervention on new archs; Unless we force the autobuilders
> to run the autotools target, in which case, it has the same problems the
> clean target had.

Absolutely.  I don't think there is an easy way to allow the autobuilders
to do that.  In this point, my concern is unchanged.

We certainly would need to be more careful with how we provide the complete
source to the users.  I have sympathy with the position that the whole
source code is available somewhere, somehow, but it is a bit harder to meet
the requirements of the GPL.  I hope that the GPLv3 will make it easier
for us to meet the requriements of providing the source (the GPLv2 was written
when broadband access was not common even in the US, as I understand).
Till then, we have to deal with its requirements.

> > > > Still, I don't want programs to call libtoolize -f in debian/rules.
> > > 
> > > Well, the only way to do that properly is to get a new debian/rules target
> > > :(
> > 
> > I hadn't thought of this solution.  It will not solve the problem of
> > out of date files in old source packages, but it would make it much better
> > because those files will be automatically updated more often.
> 
> Indeed. And we might as well teach people to stop archiving
> automatically-generated files on CVS. CVS is only for human-made files.
> gettext/autoconf/automake/autoheader/libtool-generated files DO NOT belong
> there, and should be created by an autogen.sh script upon cvs export.
> 
> Upstream needs to be taught that too, btw. I had to learn that the hard way,
> but learn it I did :)

Well, this really is an entirely different issue. :)

Thanks,
Marcus



Reply to: