Well, the discussion is raging on. Let me try to summarize, since I'm the poor schlub who has to try to document all this in the Developer's Reference.
First off, full compliance with the licensing of packages under GPL and MPL and other "keep source available" licenses (which BTW constitutes the majority of the main distribution AFAIK) *will* require a change in how we manage the Debian archive no matter what. This is not a documentation problem, and I simply cannot solve it. If a NMU includes source, the MU version of the package is gone. Our current archive scheme just does not deal with the heterogeny of package versions which exist. This heterogeny include different *upstream* versions as well as different Debian versions of packages. Since this is not a documentation problem, I'll let Guy and Ian and everyone else solve this issue. My sole concern is (a) whether or not to deprecate binary NMUs, which seem to be a great convenience to porters, and (b) to try to make porting practices more explicit, making it as easy and as functional for porters as we can. Some talk about how it is crucial to fold in porter patches into the "cannonical" Debian version. To this I agree in principle, but simply ask everyone to remember that our core compilers and libs are not the same version for all ports, and that some versions of our C++ compiler, for instance, may contain bugs which are not in other versions. Sometimes working around bugs in a specific point in time for a specific platform does not really generate the kind of diffs that one would *want* to fold into the cannonical version of a package. 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. Now granting that there are no source changes, doing a binary-only NMU is a no-brainer. But in cases where a change in the source is required (say, someone hardcoded '-i486' in CFLAGS in debian/rules), does it impose a high burden on porters to do a source NMU? 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. But again, the binary or source NMU issue is a moot point, licensing wise, until the management of source in the Debian archive is fixed. If there are any other documentation issues that I missed, please bring them up again -- it's been a long thread and a busy week. .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>
