Joey Hess <[EMAIL PROTECTED]> writes: > One wonders why you don't. Thisporting effort seems to lead to a lot of > bitter people being involved in it. One wonders why. Anyhow, TTFN.
Well, I think I can see why. Because porting is a thankless and gruelling task. You come head to head with every little packaging mistake, get bit by the flubs of newbie Debian developers and silly oversights by developers who should know better, and face the fear, hostility, and a general lack of understanding by quite a few (i386-centric) Debian folks. I think this whole discussion got off on the wrong foot because the issues got confused. Let's try to break them out so we can address them constructively. ISSUE 1: Portability or packaging fixes made by porters should propogate into the "upstream" Debian package. Solution: porters must submit bugs for their fixes to the BTS This is *already* the case, so this is a non-issue, IMHO. Asking porters to wait for the upstream maintainer to respond and fix the bug does *not* scale to the level of packages that porters routinely have to deal with. I think that porters should be allowed and encouraged to do binary-only NMUs + BTS bug filed against package (which some caveats, see licensing below). Asking porters to wait is basically like trying to kill the porting effort, which Mssr. Hess should try to realize. ISSUE 2: There are a lot of common errors made by package maintainers, i.e., wrong architecture in debian/control, leaving 'debian/files' in the source package. Solution: work with the lintian maintainer and have error conditions or warnings generated for these cases, if it is not already the case. Write a section for the packaging manual on dos and don'ts based on the unique experience of the porters. ISSUE 3: Binary-only packages w/o source may break some licenses. A lot of this comes down to whether distributing source via the ftp archive, and patches via the BTS, conform to a given license's requirements. This issue is being hashed out in <debian-policy>, so I really don't want to go into it here. Basically my stand is that assuming that the patch has been submitted to the BTS, porters should simply be able to state in the changelog something like "patches for this port available on the Debian Bug Tracking System <URL:http://www.debian.org/Bugs>". I think it's important that our ass is covered for GPL and NPL and MPL packages (or any license w/ the source availability requirement), but I really don't think ports can succeed if uploading binaries with minor portability fixes is a major hassle. Any other issues? I'm about to go toddle off to the Developer's Reference and add a section for porters. I think a clearly documented practice for porters would be a good thing, i.e., less verbal lore for porters to have to know, so becoming a porter would be easier, and more comprehension of the process by x86-centric maintainers. .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>