BIND 10 #1246: socketcreator breaks "FROM_SOURCE" environment

[BIND 10 Development]

#1246: socketcreator breaks "FROM_SOURCE" environment
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20111025
                   Priority:  major  |            Resolution:
                  Component:  Boss   |             Sensitive:  0
  of BIND                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  2
            Defect Severity:  High   |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:13 jinmei]:
 > Replying to [comment:12 jelte]:
 >
 > >
 > > However, I did unify it in the sense that it'll now set a global
 > > variable in the 'big' check right at the start (so at least the
 > > environment variable name is only used once). Updated the several
 > > checks for the environment variable to use that one.
 >
 > Okay, but the LD PATH hack is expected to be a very short term
 workaround,
 > and when it's resolved the "AND_LD" part in ADD_LIBEXEC_AND_LD_PATH will
 > be meaningless.  I'd rename it to something a bit generic, e.g.
 > ADD_INSTALLED_PATHS.  Or we might simply say ADD_LIBEXEC_PATH and
 > add a comment to the "LD" part that we abuse this variable name for a
 > short term hack.
 >

 haha, i had originally made it ADD_LIBEXEC_PATH but then ran into the
 LD code :p

 Changed it to ADD_LIBEXEC_PATH and comment.

 > >
 > > since this test is last, if they actually change the environment, it
 > > would show (note that both the deepcopy and the environment check fix
 > > this, so to see the test failing you'd need to revert all changes).
 > >
 > > But if the order isn't guaranteed, or if we feel this is relying too
 > > much on unittest framework implementation details, we could also make
 > > this a helper function and add it to the end of all tests. Would you
 > > prefer that?
 >
 > I don't know if the order is guaranteed or not by the unittest module
 > specification, but I'd generally avoid relyin on test orders.  We might
 > want to disable other part of the tests or we might want to reorder
 > the tests, and I'd like to make it less susceptible to such events.
 >

 ok, added a call to it to the end of the check_started methods (so it
 will be called in every test that checks whether things have or have
 not started)

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