On Sun, 22 Jul 2001, Marcus Brinkmann wrote: > I think there are error sceanrios. If you build the source, and then a new > autotools-dev will be uploaded and installed by the autobuilder, and then > the package is build on that. AFAICS, the build will update the scripts, > as the clean target is called by dpkg-buildpackage. Yes, it will. And since autobuilders usually do binary NMUs instead of source ones, this *might* be a problem with the GPL. 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. > This does probably not happen for the currently up to date ports (or is > unlikely), but it happens for lagging ports frequently, and certainly > happens for new ports which compile the whole archive from scratch. Well, a tread about the issue should be started in debian-legal, then. > > 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. BTW, the track-leaving autotools-dev makefile snippet was added only a few weeks ago, when someone complained about the above problem :) 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. Even if something happens to me, you need simply to request the proper version (by date) in the GNU config CVS repository... I use the CVS last check-in date as the version control numbering for this reason. > > Autotools-dev has a lot to do with the configure script, and little to do > > with the running of autoconf, automake, libtoolize or something like that to > > regenerate said script. > > I am confused. If it is the way you describe it, that the files are only > copied at source package build time, I am absolutely happy. What I have > problems with is copying them at binary package build time. Well, it IS like that. autoconf and automake do not need config.sub/config.guess, but the stuff they generate does, AFAIK. libtool, however, may need config.sub/.guess at libtoolize time; I am not certain about that, my libtool knowledge is not that good. > > A proper target for pre-build setup would be a good thing IMHO. I don't like > > using the clean target for that. Such a target should be used to call the > > autogen.sh scripts for when building from a CVS-exported tree, updating the > > build environment (calling autoconf, autoheader, automake, libtoolize, > > gettextize), and updating the build environment support stuff > > (autotools-dev). > > 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. > 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. > > > 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 :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Attachment:
pgpFaFncXTJuW.pgp
Description: PGP signature