Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 632618 - [TRACKER] eselect modules fiddling with package-manager controlled locations
Summary: [TRACKER] eselect modules fiddling with package-manager controlled locations
Status: CONFIRMED
Alias: None
Product: Quality Assurance
Classification: Unclassified
Component: Trackers (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
Depends on: 632576 531842 632624
Blocks:
  Show dependency tree
 
Reported: 2017-10-01 08:31 UTC by Michał Górny
Modified: 2021-07-21 00:48 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-10-01 08:31:46 UTC
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.
Comment 1 Benda Xu gentoo-dev 2019-05-29 13:18:55 UTC
Michal, what's your recommendation for dealing with headers and static libraries?
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-05-29 13:21:08 UTC
(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.
Comment 3 Benda Xu gentoo-dev 2019-05-29 13:49:17 UTC
(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!