Re: [PATCH] make capabilities support optional

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 5488 bytes --]

On Monday 26 April 2010 11:12:40 Chuck Lever wrote:
> On 04/24/2010 12:42 AM, Mike Frysinger wrote:
> > On Friday 23 April 2010 16:09:27 Chuck Lever wrote:
> >> "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?

it's trivial to include the full ChangeLog in the dist tarball without keeping 
it in git.  plenty of GNU projects are doing this already.

> 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.

expecting anyone who sends a patch to be fully versed in NFS internals and the 
full history is completely unreasonable.  i'm not saying people shouldnt do a 
little research here, but your position appears to be poor: if you want nfs-
utils info, regardless of who you are, you must go to the scm source and dive 
through mounds of history and divine the answer yourself.

> > 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.

the interface is irrelevant -- you're still saying people have to dig through 
piles of information that is not relevant to packaging.

> >> 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?

you're saying distro maintainers are expected to subscribe to the development 
list and review patches ?  that's bunk.

> 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?

create a list/alias maintainers can subscribe to and anytime you want to ask 
them a question, cc that.  i used to be on the nfs list but there is way too 
much noise going through about crap i dont care about.  i'm not going to wade 
through it all to find the one e-mail a month that is relevant to me.

> 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.

perhaps, but some people are ok with that.  considering that has always been 
the behavior then, ive never seen one complaint about this via Gentoo.  clear 
documentation explaining the tradeoffs would be sufficient and there are 
plenty of systems where this bug is meaningless.  on my nfs servers, either 
everything is up, or everything is down.  there is no "in between" where some 
services are left running while others are not.

> 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

i already stated my logic pretty clearly in previous e-mails.  nfs-utils 
provides no documentation, libraries get dropped in arbitrarily, so i made 
things optional.

> (and that's all I have right now because the actual patch was never publicly
> posted).

go read a mailing archive then.  not my problem if your client ate 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.
> 
> 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.

the view of distro maintainers in this regard matters more than that of 
developers.  the configure script is designed for the end packagers to use, 
not developers.  my position here is not unique to me or something i pulled 
out of nowhere.

> >> 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?

i already told you how and posted a patch: a proper configure flag should 
*always* be used to control optional non-C library linking.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]