#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