mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Alexander Dahl <post@lespocky.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH 1/2] net-snmp: improve help texts and defaults
Date: Wed, 11 Sep 2013 15:26:28 +0200	[thread overview]
Message-ID: <579b6e958fe0b6191ad4087bdd6e68f1@idefix.lespocky.dyndns.org> (raw)
In-Reply-To: <20130911130910.GE24802@pengutronix.de>

Hei hei, 

Am 2013-09-11 15:09, schrieb Uwe Kleine-König:
>> -	--disable-mib-config-checking \
>> -	--disable-mfd-rewrites \
>> +	--enable-mib-config-checking \
>> +	--enable-mfd-rewrites \

> Is this change intended? This is neither a change of help texts nor of
> defaults. So it's not documented in the change log, right? 

Yes, intended and I would call this changing defaults. Maybe I should
have made two patches, this was the first idea.

> What are the
> effects? I didn't recheck your previous mails, but wasn't one of these
> the option that you called bleeding edge?

Sort of. 

--enable-mib-config-checking is just what it claims, the option for
additional MIB modules compiled (second patch) are checked against
conflicts, doubles and the like. Without setting this option it would
just produce a warning, with this option the build fails. For example
this would be the case if someone selects the "agentx" module with the
dedicated option and also adds it to the new without-this-mib-module
option. Disabling this check would result in silently not building the
module. This is why I would prefer to set this option.

--enable-mfd-rewrites is the "bleeding edge" one I mentioned in the
other mail. Basically what I understood the upstream guys do is
rewriting some MIB modules. Disabling this options means using the old
or even ancient not rewritten module while enabling means using the new
rewritten module. This affects MIBs like the IF-MIB which are kind of
basic. Because they also claim this is a LTS branch, I would consider it
safe to set this, but this is open to discussion. However
(re)introducing this as another option to the in rule would be fine for
me as well, but the net-snmp options are already a lot so I thought it
would be enough to set a reasonable default in net-snmp.make.

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0 ***

-- 
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2013-09-11 13:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-11 12:59 Alexander Dahl
2013-09-11 12:59 ` [ptxdist] [PATCH 2/2] net-snmp: added extra menu entries for mib modules Alexander Dahl
2013-09-11 13:09 ` [ptxdist] [PATCH 1/2] net-snmp: improve help texts and defaults Uwe Kleine-König
2013-09-11 13:26   ` Alexander Dahl [this message]
2013-09-12  9:18     ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=579b6e958fe0b6191ad4087bdd6e68f1@idefix.lespocky.dyndns.org \
    --to=post@lespocky.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox