> 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
