Bug#27906: devel-ref maintainer's opinion on Binary-only NMU's
> Finally, I'd like to hear for any listening porters (Roman?) about
> why binary-only NMUs are a necessary part of their porting workflow.
> I understand they are simply a lot faster to produce in cases where
> minor, interactive style hacking is required on a package.
First to clear up a misunderstanding: I don't do bin-only NMUs that
often as it could look like now... actually, I use then rather
seldomly :-) But I don't want to miss them for the following reasons:
- In some cases, recompiles without source changes are necessary, for
example to link with different libraries. I think this case is no
problem, since there are no source changes and the GPL isn't
violated by the bin-only NMU. (Ok, one slight exception: I have to
modify debian/changelog to get my changelog entry into the binary
package... hope that doesn't make problems.)
- Sometimes it's necessary to get out a new (or first) version
quickly. This surely isn't the case if some rather unimportant
package uses a -m486 flag in the Makefile. Such a thing I'd report
as a usual bug to the maintainer, and if he doesn't react, this
package won't be available for m68k, doesn't matter much... :-)
But a different example: Assume someone has compiled a new version
of an important package and it breaks the system under some
circumstances, and this wasn't detected when testing the package.
This happens only on my architecture. The fix requires a little
source change, and the maintainer is known to be not that quick
when responding to bugs... What to do? If I go the usual procedure
of reporting a bug, waiting a few days for the maintainer to fix
it, and he doesn't respond, a lot of time is lost. Many people may
already have installed the bad package and broken their systems.
In such cases, I would prefer to take the quick alternative and
make a bin-only NMU, reporting my patch as a bug that can be
integrated later. Of course I could do an NMU with sources, but
(1) the current procedure requires me to wait at least a few days,
(2) it seems a waste of resources to force other archs (including
i386) to recompile my NMU version if nothing has changed for them.
> Because even if we solve the multiple source versions in the archive
> issue, if source NMUs are unworkable for porters for scalability
> issues we really need to try to reach some sort of situation that
> will enable porters to be effective and allow Debian to uphold our
> own goals concerning license compliance.
I still propose the possibility to put the NMU patch somewhere into
the FTP archive (additionally to reporting it as a bug). It needs not
be the real source archive, it could also be project/nmu-patches, for
example. Just to fulfill Ian's "same place" requirement...
Roman
Reply to: