[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 ryandesign@…):

 Replying to [comment:3 jeremyhu@…]:
 > The reason that the port is setup this way is to specifically prevent
 deactivation from removing contents of system directories.  What you
 suggest could be *extremely* dangerous, especially if some bug causes that
 code to accidentally remove them in the Lion+ case.
 >
 > libc++ and libc++abi first appeared in Lion, so that is why the ports
 default to +replacemnt_libcxx on SL and earlier and -replacemnt_libcxx on
 Lion and later.  The port never replaces system files on its own.  On
 Lion+, we tell the users that if they want to replace the system
 libraries, they should use darwinup to do so, so darwinup can be used to
 roll back their changes.  On SL-, we just update the host ourselves using
 the same technique (tarball root rather than destroot directly) because of
 this case:
 >
 > 1. User installs libcxx on Snow Leopard
 > 2. User updates to Lion+
 > 3. User uninstalls all ports in order to update them
 >
 > We specifically don't want to remove the (now-system-provided)
 libc++abi.dylib and libc++.dylib

 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?

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

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

 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.

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