[libcxx-commits] [PATCH] D139270: [libc++] Rename __tuple to __tuple2 to avoid file collision

[Sam James via Phabricator via libcxx-commits]

thesamesam added a comment.

In D139270#3984998 <https://reviews.llvm.org/D139270#3984998>, @tahonermann wrote:

>> Is __tuple2 acceptable to you if it's only for a single release?
>
> I don't think so. Unless I'm misunderstanding something, the same issue would occur when trying to revert to the original `__tuple` name since there is still no guarantee that a `__tuple` file from an earlier version wasn't still present.

It wouldn't, because:

- going from 15->16, __tuple gets replaced by __tuple2 (and the package manager can remove __tuple)
- going from 16->17, __tuple2 is removed, and __tuple is added (as a new directory, not a replacement of a file)

The issue is package managers often can't handle replacing a symlink directly with a directory. By having a release in between, it becomes the same as a new file.

>> That won't help with anything that uses DESTDIR/some staging area before merging to the live filesystem, unfortunately.
>
> I'm not sure I'm following. It sounds like you are suggesting there are two issues:
>
> 1. As part of the install step performed by the LLVM build system, a `__tuple` file in the install location will interfere with the installation of the `__tuple` directory.
> 2. If the target of the install step performed by the LLVM build system is a staging area, then a secondary non-LLVM process that copies/merges (portions of) the LLVM install to a live system might (or might not) encounter a problem copying/merging the `__tuple` directory if a file is present.
>
> If I have that right, then my perspective is that the second problem is not one that should be solved by LLVM. If I don't have that right, please clarify the scenario.



1. This would affect any tarball to be installed to a system (including e.g. cpack) because you can't represent that "delete the dir first" part in extraction. Build systems do not usually touch the live filesystem for this reason - it prevents any sort of staging area or packing. I don't know if LLVM produces any of these, but the fact that a few people have mentioned they've hit this outside of Gentoo means it's not specific to us at all.
2. Even if something is not _technically_ within LLVM's purview, it's often nice to distributions to accommodate them if it's not a major inconvenience. That's what the discussion above mentions -- a lot of this is about making life easier by handling it upstream briefly. It's an unusual operation to do (changing a file to a directory) and it's hit an edge-case which somebody has asked for a temporary workaround for. As explained earlier in this comment, it's sufficient for almost-all hitting this to just have it for one release, because then it's no longer a "replacement", just a "new directory".


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139270/new/

https://reviews.llvm.org/D139270