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.
You can also use "git annotate <some file>" to see exactly when
particular lines of code were introduced or change, who changed them,
and what git commit you can look at for more information.
The nfs-utils git repo is available on linux-nfs.org, and gitweb can
guide you through all of this information with a nice GUI.
If all of that fails, you can still post a question here on this mailing
list.
this
isnt the first time the nfs related packages suddenly started requiring new
libraries out of the blue when in reality things could be done optionally, nor
is this the first patch ive sent to try and address what appears to be
unnecessarily hard deps. kerberos readily comes to mind.
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.
Of course, that only works if you post to this list too. I don't see
this patch in the mailing list archives, but I may have missed something.
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.
I don't have a problem with making new features optional, when it's
necessary. What I'm objecting to here is that it's easy to add
autotools machinery, but it's a lot more difficult to check that all of
nfs-utils still works in all cases after such a change, and that the new
option doesn't introduce a regression (which it does in this case).
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.
So, why do you want to make libcap optional? And why is yet another
build option needed (rather than just using AC_FUNCTIONS and HAVE_LIBCAP) ?
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
