On Friday 23 April 2010 16:09:27 Chuck Lever wrote: > On 04/23/2010 03:29 PM, Mike Frysinger wrote: > > On Friday 23 April 2010 15:12:33 Chuck Lever wrote: > >> If we really do need to drop libcap for some configurations, then such a > >> change should be thoroughly tested in those environments. Some features > >> won't always work without libcap, and appropriate warnings should be > >> added to man pages and/or should be displayed by statd. > > > > there should be appropriate documentation regardless. current nfs-utils > > lists no information at all in ChangeLog/NEWS/README/INSTALL or any > > other document explaining why/what/how libcap is needed/used. you cant > > do documentless dumps on distro maintainers and expect them to "just > > know" what is going on. > > "git log" has served as the ChangeLog for some time now. The commits I > referenced in my last e-mail explain exactly why libcap was introduced. none of the scm metadata is relevant to distro maintainers. that info is fine for developers of nfs-utils, but that's it. people attempting to package nfs- utils shouldnt need to crawl these backends to try and glean info themselves. > Patches are posted on this mailing list for review before they are > committed. Anyone has a chance to object, comment, or suggest a simpler > way to do things. again, this isnt relevant to distro maintainers. > It's important to realize that it's much harder to make things optional > than to insist that they be built in. Adding build options means > there's more work for distributors to configure the build, and it > exponentially increases our test matrix (which is already out of > control). Every change now has to be tested with each combination of > build options. Add one more --enable option, and that doubles the > number of combinations. hardcoding optional features in autotools is worse for distro maintainers than proper optional configure flags. dont kid yourself in this regard. > I didn't see a clear explanation of why your proposed change was > necessary, nor was it clear from the patch description that you > understood why libcap was added in the first place, nor does it seem > that the regressions caused by disabling libcap are adequately addressed. things worked before libcap was introduced, so clearly it's possible. it may be reduced security footprint, but plenty of people are fine with it. > So, why do you want to make libcap optional? there are plenty of systems where privileges are meaningless (like embedded) and so libcap is pure cruft. > And why is yet another build option needed (rather than just using > AC_FUNCTIONS and HAVE_LIBCAP) ? magic detections are terrible for distro maintainers and one of the things we spend a lot of time fixing. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
