On Jan 24, 2009, Richard M Stallman <[email protected]> wrote: > Removing all the code in a driver, rather than simply disabling its > requests for non-Free firmware, creates another major burden: any patch > that touches files in that driver becomes an additional maintenance > burden.
> I don't see why. Would you explain? Here's the scenario that triggers the problem for me. I'm trying the Fedora CVS repository to build Linux-libre packages. The binaries are built following this procedure: - unpacking a source tarball (say, linux-2.6.28.tar.bz2), downloaded from upstream and verified with digital signatures. I modify this so that it downloads say linux-2.6.28-libre.tar.bz2 from our servers. - applying patches distributed by upstream to bring it up to minor releases (2.6.28.1) or to pre-releases of the next release (2.6.29-rc2, 2.6.29-rc2-git1). These days, most of the time, no changes are needed in the update patches, and changes to the pre-release patches are mostly limited to the moving about of firwmare files while Linux completes the transition to the request_firmware() API. When changes are needed, I arrange for the modified patches with '-libre' in the name to be downloaded from our servers. - applying several other patches that are available directly from the CVS repository. Some are created within the Fedora community to adjust the kernel for Fedora; some bring in fixes and improvements from various development trees. Most of them don't require any changes, but there are a few that often require attention. For example, the patches from the Linux wireless community often includes changes for firmware in certain key drivers, and nearly always modify the drivers that use such firwmare. Video Direct Rendering drivers at times requires changes because e.g. nouveau contains blobs, but sometimes they need tweaking for silly reasons such as Kconfig conflicts because the 'depends on NONFREE' marks are not present in the context in the patch. Any patch that fails to apply is proportionally a major burden. The reason I can maintain Linux-libre is that, most of the time, it takes me just a couple of minutes a day to keep up with upstream. If a patch fails to apply and requires manual intervention, this couple of minutes at the very least doubles (the bulk of the manual operation has to be repeated after fixing the error), and, when I need to tweak patches so that they apply, this may translate into tens of minutes and, in rare cases, even hours. Now, I'm not the only one affected by patch conflicts. I've seen others who wanted to build Linux-libre plus patches run into problems and even give up because of simple patch conflicts. That's an undesirable outcome. This improved when we switched from the original 'remove everything' approach taken by gNewSense at first, to the 'remove just the blobs' approach I introduced later. However, the Kconfig markers still cause errors when applying patches for unrelated features that happen to appear close enough in Kconfig for the absence of markers to cause a patch to misapply. This convinced me that it's important to minimize divergence. It's very convenient for me and for our users, and, as long as every portion, reference and allusion to non-Free firmware is removed, it shouldn't make any different in terms of ethics and morals. > When a patch tries to change a file which is not present, that part > of the patch will be ignored, right? patch will report and error, ask questions and confuse users. Besides that, removal of files requires changes to other files that are not removed, which in turn creates other patch conflicts that might be more difficult to address. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer _______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
