#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