Helmut Grohne writes ("Re: copyright precision"): > On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote: > > Perl's Configure is not a very useful example and has IMO some > > justification. I think it's poor engineering to have edited the > > output file, but that doesn't mean it's not now the source code. > > IMO it is a very good example. To determine whether Perl[1]'s Configure > is preferred form for modification, I sent a patch. It turned out that > my patch couldn't be applied, because it touched generated parts and it > was concluded[2] that Configure should be regenerated to fix the > reported issue. Demonstrably, Configure is not preferred form for > modification. Whether we call it source or not, the freedom to modify is > practically lost.
My interpretation of the situation described in #762638 and #775940 is that: AIUI in the past, Perl upstream told people to edit Configure and promised to accept patches in that form. Debian took upstream at their word. We made extensive edits to Configure and never regenerated it. Now, upstream don't seem to be taking the same line. But, we are still using an edited output file. If bugs occur in that file, we will edit it further. There is no intention on the part of Debian's Perl maintainers to regenerate it, at least, not any time soon. What this means is that we are using a fork of Configure. The source code for Debian's Perl Configure is the script itself. Originally, we should not have accepted upstream's word. When we did, we started working on a non-source form of the work, effectively forking it. But now it is too late. The same situation could in principle occur with minified concatenated Javascript. If some upstream package came with a copy of spong.js or whatever which had been minified, prettified, and then substantially edited, and for which the original creation process was no longer available, then (regrettably) we would have to conclude that the source for that version of spong.js was the file itself. In practice this is not likely to arise because of the different role of the file, and because of the, err, different style of software release management that Javascript programmers normally adopt. I think it is fair (indeed, very wise) to block new occurrences of this kind of problem. I don't think it is sensible to try to throw out packages containing existing occurrences. For now, for Perl, I think my analysis shows that someone like you who wants to improve Configure is entitled to produce a patch (semi-automatically-generated, if necessary - in which case provide the scripts or perl runes or whatever for records in BTS and source package) to the Perl Configure. The Perl maintainers should accept it. If anyone arranges to package metaconfig for Debian and to regenerate Perl's Configure, your patch can simply be dropped on the grounds that it's now unnecessary. That would constitute us dropping our fork of Configure. But in the meantime, while we have that fork, we have to allow people who need to edit it, to do so (and that includes accepting their patches). > Another place where the inability to build from source has hampered > progress was blt #772590. That's an instance of the old not-rerunning-autoconf chestnut. There are practical advantages providing a pregenerated configure (for people who don't have a suitable autoconf), and practical problems with providing a pregenerated file and then routinely overwriting it. > Other packages that don't build from source by default include bash, > dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc, > libatomic-ops, libbsd, libtasn1-6, lzo2, ncurses, nettle, patch, > readline6, and sed. I agree that in general we should build from source. Are these all autoconf ? > > Are you seriously suggesting that I actually propose a MBF ? > > If you think that our current practice is wrong, isn't it logical to do > so? I'm not sure how I would even find all the packages affected. And I agree with your other mail, about not filing bugs which no-one will work on. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.