Perl Configure mess (mostly) (Re: copyright precision)
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 <ijackson@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.
Reply to: