Re: Do the HPPA "binary-only" NMUs violate the GPL?
>>>>> "LaMont" == LaMont Jones <lamont@hp.com> writes:
>> > clif (0.93-1.0.1) unstable; urgency=low > * va_arg fixes for
>> gcc 2.96 and later. See #103683 This is certainly in poor
>> taste. If the HPPA people can't wait for the maintainer to
>> turn around a new package, they should do a source NMU - it's
>> scarcely much more work than a binary-only upload. Like any
>> other, this rule is made to be broken, but one shouldn't make a
>> habit of it.
LaMont> As the one doing a fair percentage of these uploads, here
LaMont> is the logic I was given by some porters (who have done
LaMont> other architectures) when they told me to do binary NMU's
LaMont> with a patch in the BTS.
LaMont> 1) GPL is met, since the source is available. All
LaMont> information needed to get the source is provided in the
LaMont> ftp archive and the .changes file.
I sort of doubt this meets the GPL, but even if it does I don't think it is a good idea.
LaMont> 2) there are long
LaMont> build-dependency chains which take forever to get built if
LaMont> one package takes time to get there. In order for the
LaMont> build daemon to find the package, it must be in the
LaMont> archive.
But you really need a solution to this problem.
LaMont> thoughts? lamont
Do the binary upload but make sure no such packages are released.
I.E. if you are working on a released architecture open the bug as
serious so it will block your upload from going into testing. If you
are working on a non-released architecture, upgrade the bugs or do
source NMUs to make sure that these packages never make it into a
release when your architecture is ready to release.
The other option is to ignore process and do rapid source NMUs but that seems like a very bad option.
Personally I would find it unacceptable if one of my packages were
released with the source code not corresponding to diff+tar.
Reply to: