Although the `nerd-icons` package is currently within the `app-emacs` category, a discussion on #gentoo today suggests it users can confuse the package with media-fonts/symbols-nerd-font, particularly if they're primarily wanting the icons from the latter. Upstream actually calls itself `nerd-icons.el`: https://github.com/rainstormstudio/nerd-icons.el which (as a developer of Emacs packages myself) i assume is an attempt to make it clear that this is an ELisp package, and not the icons component of Nerd Font. Thus, taking package naming requirements into consideration, could the package be renamed `nerd-icons-el`? A possible objection is that some users might assume `el` refers to the ISO 639 code for Greek. i don't know to what extent that might outweigh trying to disambiguate app-emacs/nerd-icons from media-fonts/symbols-nerd-font.
I very much agree with this suggestion. I had faced this issue today, when i wanted to uninstall app-editors/emacs, but couldn't find the entry on the world favorites file list. Then I had to go around the rabbit hole to find which packages depended on emacs and which one actually pulled in. Finally figured out that app-emacs/nerd-icons pulled in app-editors/emacs, which made me realize that i should have installed the media-fonts/symbols-nerd-font instead of app-emacs/nerd-icons. Implementing this suggestion would help in preventing confusion.
There are quite a few packages in app-emacs that have an identical name as packages in other categories. That's what categories are for. Here the argument is even weaker, because the package name is different. So not sure how any confusion could arise? Historically we had (and still have) some Emacs packages that end in "-el" but we generally avoid this nowadays.
This whole debate comes from misunderstanding of Gentoo package categories. To want to have some additional emacs- prefix or -el suffix **only** to distinguish the package as belonging to A category is throwing away the whole categories concept. Sure we are sometimes lazy and leave emacs- or -el but then we do not have to modify the handling of PN, P, S etc inside ebuild, in case of nerd-icons.el we already had to do so, so I decided to strip it. > Then I had to go around the rabbit hole to find which packages depended on emacs and which one actually pulled in. "emerge -c -p -v emacs" is a rabbit hole? Portage will gladly tell you what package X pulls in package Y. > Finally figured out that app-emacs/nerd-icons pulled in app-editors/emacs, which made me realize that i should have installed the media-fonts/symbols-nerd-font instead of app-emacs/nerd-icons. Yes, you should have installed the other pkg since app-emacs/nerd-icons is meant for Emacs only. I you need fonts for use under you only user install them manually and for system-wide use - pkgs from the media-fonts category. And here is the output of command I mentioned above, very clear: > magentalane-0-workstation /etc/portage > -> emerge -cvp emacs > > Calculating dependencies ... done! > app-editors/emacs-31.0.9999 pulled in by: > app-admin/emacs-updater-1.18 requires >=app-editors/emacs-23.1:* > app-emacs/ace-window-0.10.0 requires >=app-editors/emacs-25.3:* > app-emacs/all-the-icons-5.0.0_p20230316 requires >=app-editors/emacs-25.3:* > app-emacs/all-the-icons-dired-2.0 requires >=app-editors/emacs-25.3:* > [...]
For myself, i accept this bug being closed as RESOLVED WONTFIX. Certainly people need to pay attention to Gentoo categories, both when searching for packages and when creating ebuilds. (Although of course that still has its limitations, not least to due to upstream: it turns out `dev-cpp/ada` is not actually a C++ library providing Ada-related wrappers, but a URL parser.) That said, i'd like to make a comment regarding: > some additional emacs- prefix or -el suffix **only** to distinguish the package as belonging to A category i feel there is a distinction to be made here between ELisp-based packages which have `.el` as part of their 'official' name - as i noted is the case with `nerd-icons.el` - and packages which don't. As an example, my `Ebuku` ELisp package doesn't include `.el` as part of its official name, and so i wouldn't expect it be packaged by Gentoo as `Ebuku.el`; `ebuku.el` is merely the name of the single source file in the package. On the other hand, the `debian-el` and `speechd-el` ELisp packages both literally include `-el` as part of their official name (as per `M-x package-list-packages`), and indeed, the Gentoo package for `speechd-el` is `app-accessibility/speechd-el`.
(In reply to Alexis from comment #4) > > some additional emacs- prefix or -el suffix **only** to distinguish the > > package as belonging to A category > > i feel there is a distinction to be made here between ELisp-based packages > which have `.el` as part of their 'official' name - as i noted is the case > with `nerd-icons.el` - and packages which don't. > > As an example, my `Ebuku` ELisp package doesn't include `.el` as part of its > official name, and so i wouldn't expect it be packaged by Gentoo as > `Ebuku.el`; `ebuku.el` is merely the name of the single source file in the > package. On the other hand, the `debian-el` and `speechd-el` ELisp packages > both literally include `-el` as part of their official name (as per `M-x > package-list-packages`), and indeed, the Gentoo package for `speechd-el` is > `app-accessibility/speechd-el`. From "M-x list-packages RET" output: nerd-icons 20240816.1555 new melpa Emacs Nerd Font Icons Library
And yet, the name of the upstream repo is 'rainstormstudio/nerd-icons.el', and the README has: > nerd-icons.el - A Library for Nerd Font icons and > Nerd-icons.el is a library for easily using Nerd Font icons inside Emacs, an alternative to all-the-icons. So i feel the most appropriate thing to do would be to ask the package author to clarify; i don't feel it's appropriate for Gentoo to make a decision what the package name 'really' is without first seeking the author's input.
> So i feel the most appropriate thing to do would be to ask the package author to clarify; i don't feel it's appropriate for Gentoo to make a decision what the package name 'really' is without first seeking the author's input. One might say that this is some discussion that should be carried out on some "(F)OSS social-contract" ground. But lets think about this in terms of identity. Simply: project != package Thus, name of *package* should follow the *project* or app, exe, binary, doc, whatever, but this is no matter in which the project maintainer has *definitive* say.
