Seems to be unnecessary.
texlive-core-2017-r3 currently has these X dependencies: x11-libs/libXmu x11-libs/libXp x11-libs/libXpm x11-libs/libXaw However, it looks like only the following are actually needed: - mf, inimf, and mflua* link against libX11. - pdf{open,close} link against libX11 and libXmu. (It doesn't seem to call any function from the latter, but there's an explicit -lXmu in the build log.) So dependencies could be reduced to x11-libs/libX11 and x11-libs/libXmu.
(In reply to Ulrich Müller from comment #1) > - pdf{open,close} link against libX11 and libXmu. (It doesn't seem to call > any function from the latter, but there's an explicit -lXmu in the build > log.) I have reported the unnecessary libXmu dependency upstream (but no reply yet): http://tug.org/pipermail/tex-live/2018-March/041243.html
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3c7af84b0249e361487b7dfe866543dd76b83880 commit 3c7af84b0249e361487b7dfe866543dd76b83880 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-04-02 12:59:42 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-04-02 13:00:27 +0000 app-text/texlive-core: Fix dependencies on X libraries. For the time being, keep the dependency on libXmu (linked against by xpdfopen). Closes: https://bugs.gentoo.org/649152 Package-Manager: Portage-2.3.27, Repoman-2.3.9 app-text/texlive-core/texlive-core-2015-r1.ebuild | 6 ++---- app-text/texlive-core/texlive-core-2016-r5.ebuild | 6 ++---- app-text/texlive-core/texlive-core-2016-r6.ebuild | 4 +--- app-text/texlive-core/texlive-core-2017-r2.ebuild | 6 ++---- app-text/texlive-core/texlive-core-2017-r3.ebuild | 4 +--- 5 files changed, 8 insertions(+), 18 deletions(-)
I have filed bug 652212 for the xpdfopen / libXmu issue which is somewhat separate from this (and not a blocker for libXp removal).
This change has been done without appropriate revbump. As a result, a number of users is going to see that libXp is p.masked but won't be able to unmerge it properly due to still-present dependency in already-built texlive-core.
(In reply to Michał Górny from comment #5) > This change has been done without appropriate revbump. As a result, a > number of users is going to see that libXp is p.masked but won't be able to > unmerge it properly due to still-present dependency in already-built > texlive-core. I believe that this is well within the scope of current policy: https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Especially, we're not adding a runtime dependency. Removal of libXp from RDEPEND cannot possibly break anything on the user's system, neither if libXp is unmerged nor if it is not.
Or in other words, the trade-off is between a tiny library (libXp.so.6.2.0 has a size of 36 KiB here) remaining on the user's system until the next revbump, versus the cost of rebuilding a large package like texlive-core.
I just ran into this bug because emerge asked me to unmask libXp again. Revbump would have saved me a little bit of time to investigate the cause.
Same here, I lost more time finding out that texlive-core needed a rebuild than actually rebuilding it. This seems to be something that portage could report, along the lines of "Rebuild X to be able to remove these packages". ... or just revision bump it.
(In reply to Till Schäfer from comment #8) > I just ran into this bug because emerge asked me to unmask libXp again. > Revbump would have saved me a little bit of time to investigate the cause. You can unmask libXp, or unmerge it, or do nothing. Neither of these actions will cause any breakage on your system. (In reply to Mathy Vanvoorden from comment #9) > Same here, I lost more time finding out that texlive-core needed a rebuild > than actually rebuilding it. It doesn't need a rebuild. There is no harm in keeping libXp installed (see comment 7 above, it is a tiny library). Eventually it _will_ be dropped, e.g., with the next version bump of texlive-core.
