Re: Do the HPPA "binary-only" NMUs violate the GPL?

[LaMont Jones <lamont@hp.com>]

> Sure.  Binary-only NMUs from modified source have always been a useful 
> technique for getting a new port off the ground, or for quickly fixing a 
> grave but port-specific bug in an important package.  But they do break the 
> assumption that you can do "apt-get source ..; dpkg-buildpackage" to 
> reconstruct an equivalent binary package, which could be a nuisance if there 
> is a risk that these packages might end up in a release.

Each and every one of the binary-NMU's-with-a-patch has an RC defect against
the package.  (If not, let me know and I'll file one...)

Before woody releases, each of these RC defects will need to be resolved.
If the resolution is to downgrade the defect, then it means that hppa
and/or ia64 didn't make the release, and shouldn't be in the archive.

Our group plans to do a sweep of the archive looking for binary nmu's for
hppa and ia64 and doing source NMU's (with warning) prior to the package
freezing.

> It sounds like these modified binary NMUs might have become a standard modus 
> operandi for HPPA, and this definitely isn't a precedent that ought to be set.

I've been trying to just do it for (1) resolving build-deps, or (2) packages
that we need for testing.  But sometimes it's been "fix the problem in 40
packages".  In that case, some of the packages uploaded have met none of the
above.

The number of touched packages is also larger because of the gcc 2.96 (for
ia64) and gcc 3.0 (for hppa) requirement, which is uncovering a lot of
"but that didn't used-to-be an error" code constructs.

>   In particular, it seems
> fairly inappropriate to do a modified binary NMU and mark it "urgency=low".

I've been doing the uploads with the same urgency as the package had when
originally uploaded, since it's not fixing any functionallity, just porting
work.

lamont