[MacPorts] #49903: libcxx: undo changes to system directories when deactivating

[MacPorts]

#49903: libcxx: undo changes to system directories when deactivating
---------------------------+------------------------
  Reporter:  ryandesign@…  |      Owner:  jeremyhu@…
      Type:  enhancement   |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.3.4
Resolution:                |   Keywords:
      Port:  libcxx        |
---------------------------+------------------------

Comment (by jeremyhu@…):

 Replying to [comment:4 ryandesign@…]:
 > That's an excellent point that I had not considered. But wouldn't it be
 a simple matter of checking the OS version to handle that? The post-
 activate block in the portfile that untars the tarball is already guarded
 by a check that os.major < 11. Wouldn't guarding my proposed pre-
 deactivate block in the same way be sufficient to avoid the scenario you
 described?

 Yes, but it just doesn't sit well with me.

 > > The disk space cost of having 2 dylibs (libc++abi and libc++) that the
 user might not need any more on their system is far less than the
 potential risk of things going wrong because we removed the dylibs.
 >
 > I'm not concerned about the disk space; I'm concerned about unregistered
 components being left on the user's system which might have an effect on
 it. For example, software like aria2 that checks for libc++ would find it
 and would build against it.

 Shouldn't aria2 be honoring configure.cxx_stdlib?

 > > I'd feel more comfortable giving instructions in deactivate than
 actually doing the work there.  Would that be acceptable?
 >
 > I'm looking for a solution that also works on the buildbot buildslaves,
 where builds happen automatically and nobody is reading instructions. I
 don't want the installation of one port that declares a dependency on
 libcxx (as I propose to do for aria2 via a modification to the libcxx
 portgroup) to cause libc++ to be permanently available on the Snow Leopard
 build slave and potentially cause other ports built on that build slave to
 build differently in the future.

 Wouldn't that then be a bug in those other ports for not honoring
 configure.cxx_stdlib?

 > Hmm... In fact, this has already occurred, of course. The moment the
 libcxx port was created, the buildbot built it, which caused libc++ to be
 installed on the Snow Leopard build slave, and since the port doesn't
 clean it up afterward, it's still installed. I guess the only ports that
 would actually have a chance of using it are those that already require a
 newer clang.

 Right.

 I'm not saying no, I'm just nervous about potential problems here as this
 is a delicate area.

-- 
Ticket URL: <https://trac.macports.org/ticket/49903#comment:5>
MacPorts <https://www.macports.org/>
Ports system for OS X