Let's finally start tracking eselect modules that alter package-manager managed locations such as /usr/bin, /usr/lib* and so on. Rationale: - those directories are reserved for package manager actions, eselect modules create orphan files there that cause painful collisions when we fix them, - those modules do not respect host configuration concept -- they do not work correctly when /usr is shared between multiple systems, - they are also broken when /usr is mounted read-only, - even worse, a number of them are used to control build-time dependencies (e.g. a package links to whatever library eselect selects, instead of the one specified as a dependency), - [semi-related but usually fixed the same way] the error handling is unreliable and the eselect modules can leave symlinks in bad, inconsistent, hard-to-fix-properly state when they fail. Usual replacements: - configuration files in /etc or /var, - PATH manipulation (env.d) putting appropriate executables (symlinks) on top of PATH rather than recreating symlinks in /usr, - LDPATH manipulation (env.d) for ensuring that the libraries are found, - eclass/ebuild logic + USE flags for selecting between alternative implementations of libraries.
Michal, what's your recommendation for dealing with headers and static libraries?
(In reply to Benda Xu from comment #1) > Michal, what's your recommendation for dealing with headers and static > libraries? Always use reference headers and libraries to build stuff. Or just put proper -L/-I flags to any implementation if they are truly compatible.
(In reply to Michał Górny from comment #2) > (In reply to Benda Xu from comment #1) > > Michal, what's your recommendation for dealing with headers and static > > libraries? > > Always use reference headers and libraries to build stuff. Or just put > proper -L/-I flags to any implementation if they are truly compatible. Hmmm, I quickly had an answer myself. The should be only 1 set of headers, and should be shared by all the implementations by definition. headers don't need to be switched. Agree with you. We should ban eselect switch of static libraries, otherwise eselect would cause an impact on the build time behavior. Nice and clear. Thanks!
Using eselect-emacs as an example, I see two alternatives to fix this: 1. Have a double-step link, e.g. /usr/bin/emacsclient -> /etc/emacs/emacsclient -> /usr/bin/emacsclient-emacs-28. The eselect module would then update the link in /etc/emacs. 2. Wrapper script, e.g. /usr/bin/emacsclient would be a bash script reading a config file in /etc/emacs and then exec the appropriate variant. Option 1 seems simpler and more efficient. Is there anything that speaks against it? A problem with both options is that there can be stale symlinks or wrappers. For example, previous Emacs versions came with grep-changelog and rcs-checkin commands, but these are no longer provided by newer versions. If we want /usr/bin to be static, we would have to place them there in any case.
