BIND 10 #1292: Xfrin retransfer shared object "sqlite3_ds.so" not found

BIND 10 Development do-not-reply at isc.org
Thu Nov 24 04:42:02 UTC 2011


#1292: Xfrin retransfer shared object "sqlite3_ds.so" not found
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20111206
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  High   |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  5      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:20 jelte]:

 First, this point:

 > BTW, I have not checked, but if this works, i suspect it solves several
 other related tickets as well (#1385 and #1421, maybe more)

 For #1421, probably.  I suspect #1385 is a separate issue.

 About the branch:

 '''general'''

 I'm not very happy about introducing yet another hardcode of things
 like B10_FROM_BUILD in our main source code.  Is the plan to have this
 as a short to middle term workaround and eventually replace it with a
 more generic framework?  If so, I can live with that (but please make
 that clear in comments).  If not...we should discuss it:-)

 '''datasrc_config.h.in'''
 - We need a header guard for this file.
 - I'd avoid using macro whenever possible, and I think in this case we
   can avoid that (it should be able to be a const char* const).  I'd
   also put the definition in a namespace isc::datasrc.
 - We need documentation for MODULE_PATH.
 - Although this is independent from the topic of this ticket, I
   personally think @prefix@/lib is not the right place for loadable
   modules for two reasons: 1. they are not really "libraries", 2. they
   are quite BIND 10 specific.  So I'd suggest changing it to
   @localstatedir@/@PACKAGE@/modules (which would be expanded to
   something like /usr/local/libexec/bind10-devel/modules), either
   within this ticket or in a new ticket after creating it.

 '''bind10_src.py.in'''

 Why did you reintroduce start_zonemgr and start_stats?  Also, although
 this is a subject of #1388, we should actually even be able to
 obsolete (i.e. remove) start_xfrout() and start_xfrin() and remove
 XfrIn/XfrOut from isc.bind10.special_component.py (and these would
 also require updating bob.spec).

 We could leave this task to #1388 as originally planned, or complete
 that part within this ticket.

 '''factory.cc'''
 - maybe a matter of taste in the case of std::string, but I suggest
   using empty() instead of length() == 0:
 {{{
     if (type.length() == 0) {
 }}}
   At least for some STL containers that's a better practice, and I
   think using consistent convention would make sense here, too.
 - I'd also move the definition of lib_file just before its first use:
 {{{
     std::string lib_file = type;
     const int ext_pos = lib_file.rfind(".so");
 }}}
 - Don't we need a test for getDataSourceLibFile?

 '''datasrc/tests/Makefile.am'''
 - Why was this commented out, not simply removed?
 {{{
 -run_unittests_SOURCES += factory_unittest.cc
 +#run_unittests_SOURCES += factory_unittest.cc
 }}}
 - Regarding run_unittests_factory, if the intent is as commented:
 {{{
 # Also, we only want to do this when static building is not used.
 }}}
   Shouldn't we wrap this with "if !USE_STATIC_LINK/endif"?

 '''lettuce bind10_control.py'''

 I've not confirmed this by running it, but is this okay?

 {{{#!python
     result = bindctl.wait()
     (stdout, stderr) = bindctl.communicate()
 }}}

 According to the documentation communicate() seems to have the
 functionality of wait().

 '''lettuce xfrin_bind10.feature'''

 I'm afraid I'll need to learn more about lettuce to understand this
 change.  I'm willing to do that, but it will take some time.  For now,
 maybe it's better to have someone more familiar with lettuce (if any)
 quickly review and approve it.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1292#comment:21>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list