On 04/24/2010 12:42 AM, Mike Frysinger wrote:
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.
Obviously, that metadata _is_ relevant to distro maintainers, as your
example shows. The nfs-utils ChangeLog is an exact copy of the the git
log (up to about mid 2006). Why keep an extra copy?
However, as soon as a distributor sends patches (rather than, say,
simply posting a bug report), you become a developer, and are thus
obligated to act like one by reviewing the content of the local source
management system before making changes, and by posting your patches to
this list for us to review.
people attempting to package nfs-
utils shouldnt need to crawl these backends to try and glean info themselves.
As I pointed out, you don't need git on your local system to look at
this metadata: it's already available on linux-nfs.org if you have a web
browser.
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.
How are nfs-utils developers supposed to know of a problem if distro
maintainers don't tell us?
I specifically asked on this list about libcap before adding it. We've
been discussing the addition of libsqlite and libtirpc as well, and I
specifically requested feedback from distributors. There was no
response. So how are we supposed to know these are problems? Where
else should I have asked this question?
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.
I claim that "things" did not work. When statd was shut down, it left a
dangling rpcbind registration, and that's a bug in all environments.
If my bug fix is not complete or is inappropriate for some environments,
then we should have a discussion about that. It's pretty hard to tell
what you were trying to address from your patch description (and that's
all I have right now because the actual patch was never publicly posted).
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.
In that case, your patch description should explain that so we can
understand why you've added another --enable switch. These switches are
overused, so a clear rationalization is needed when adding yet another.
By and large, those who participate on this list felt that "--enable"
flags are less desirable than automatic feature checking. Your view is
novel, I think.
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.
nfs-utils uses autotools, so that's what we have. How else should it be
done?
--
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
