If youtube-dl is replaced by yt-dlp, Portage messes up the symlinks: * * Installation of a symlink is blocked by a directory: * '/usr/lib/python3.10/site-packages/youtube_dl' * This symlink will be merged with a different name: * '/usr/lib/python3.10/site-packages/youtube_dl.backup.0000' * (etc.) As a result, once youtube-dl is unmerged, there is no 'youtube_dl' package, just 'youtube_dl.backup.0000'. If you want to use the symlink approach, you need to have a hard blocker on youtube-dl, so the user unmerges it before emerging yt-dlp. Alternatively, it might be possible to use some fancy loader-based solution instead. However, I don't really know how to do that. Please consider this urgent as I'd like to lastrite youtube-dl.
Bleh, missed that given it still installs. >Please consider this urgent as I'd like to lastrite youtube-dl. Had a bit of summary for remaining youtube-dl stuff in bug #829501 comment #5 which may help if you want to last-rite (there's optfeatures to consider too) -- although upstream got a new maintainer and it been active. About symlink, long term not sure how useful it'll be to keep -- it's not 100% compatible and only works for very basic packages. I feel what I previously suggested, aka keeping youtube-dl, allowing it to coexist (with a USE to not install the command, aka module-only), and removing the symlink is the better approach for as long as youtube-dl upstream is active. I could take over youtube-dl maintenance to do that. I tried using a hard blocker but portage now just refuse to auto-resolve this for me, if possible I'd rather just remove it and keep youtube-dl.
(In reply to Ionen Wolkens from comment #1) > I could take over youtube-dl maintenance to do that. After talking, will likely be going that route (for now) and prepare updates (symlink will be removed). Not that excluding last-riting youtube-dl on the long term, but I feel it's too early with some upstreams still relying on youtube-dl's implementation and youtube-dl itself perhaps not being dead after all. Not most elegant solution but it simplifies things and will migrate users to yt-dlp by default for the command (not the module which isn't compatible). Then packages can depend on either depending on what they're written for.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80090cb504a4303d1845f50226b1e0a073e8c6f4 commit 80090cb504a4303d1845f50226b1e0a073e8c6f4 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-02-15 23:09:27 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-02-16 02:53:42 +0000 net-misc/yt-dlp: remove youtube-dl python module symlink This was never a good idea, it's not 1:1 compatible and cases where yt-dlp's python module can work on a package expecting youtube-dl are rather few (sometime can do some basics at best). And then portage is not good at handling this situation wrt bug #833435 Fortunately no revdeps relied on this yet, so cleaning should be safe (vidify was patched to import the right module instead, so +1). Also adjust youtube-dl blocker to account for upcoming IUSE=yt-dlp. Closes: https://bugs.gentoo.org/833435 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../yt-dlp/{yt-dlp-2022.2.4.ebuild => yt-dlp-2022.2.4-r1.ebuild} | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)
