[Nix-dev] Seemingly inexplicable proliferation of gcc/glibc runtimes

Kosyrev Serge _deepfire at feelingofgreen.ru
Sun Jul 24 19:37:15 CEST 2016


Good day!

I am trying to understand the reasons for the multiplicity of glibc/gcc
runtimes installed on my NixOS system -- on fresh nixpkgs master (434f9d1).

The status quo is a system with:

 - a single system profile (system-290-link)
 - a single user profile (profile-483-link)
 - an empty root user profile (default-4-link)

,----
| deepfire at andromedae:~]$ nix-store --gc --print-roots
| /nix/var/nix/profiles/default-4-link -> /nix/store/vvm18ixrgpn9zgzp5h3lkiyx6rqfj3qn-user-environment
| /nix/var/nix/profiles/per-user/deepfire/profile-483-link -> /nix/store/bg1z2vwb28my9grrpnc192a3c3sq3l8d-user-environment
| /nix/var/nix/profiles/system-290-link -> /nix/store/y79r2dj7qymfhi9zdirdpfppbv4jbzqp-nixos-system-andromedae-16.09.git.434f9d1
| /run/booted-system -> /nix/store/y79r2dj7qymfhi9zdirdpfppbv4jbzqp-nixos-system-andromedae-16.09.git.434f9d1
| /run/current-system -> /nix/store/y79r2dj7qymfhi9zdirdpfppbv4jbzqp-nixos-system-andromedae-16.09.git.434f9d1
`----

Additionally:

 1. everything in the user environment was passed through 'nix-env --upgrade --leq --always',
    so it ought to be completely synchronized with nixpkgs=434f9d1

 2. the booted system environment == the current system environment, as
    it can be seen

 3. there seems to be no pinned custom environments that I could find --
    not that I ever made one, actually

 4. nix-store --gc, obviously

What I see is this:

,----
| [deepfire at andromedae:~]$ nix-analyze-rootlike glibc; nix-analyze-rootlike gcc
| ; analyzing "/nix/store/*-glibc-*" (minus noise)
| referrers	| disc	| correlation to profile
| closure	direct  | size	| user	system
| 1073	807	| 22M	| 109	25	/nix/store/dad9vxniabwzidvvxfsfj6vb0xncsbbb-glibc-2.23
| 210	165	| 22M	| 0	0	/nix/store/phffgv3pwihmpdyk8xsz3wv8ydysch8w-glibc-2.23
| 159	22	| 34M	| 0	0	/nix/store/i0l0jjkk82wsqz9z5yhg35iy78bjq684-glibc-2.21
| 5	5	| 22M	| 0	0	/nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
| ; analyzing "/nix/store/*-gcc-*" (minus noise)
| referrers	| disc	| correlation to profile
| closure	direct  | size	| user	system
| 388	10	| 116M	| 42	8	/nix/store/scfqn95555hsh9k1b0j1y1znzrkr2a5k-gcc-5.4.0
| 148	5	| 91M	| 0	0	/nix/store/cpv8pyc772cx0spzz76sa6dvsf6555dh-gcc-4.8.4
| 7	2	| 116M	| 0	0	/nix/store/l8y2srrkp5fflwph7vq0gllj1k1ai17w-gcc-5.3.0
`----

The tools used to generate this are at https://github.com/deepfire/nix-store-analysis:

   - https://github.com/deepfire/nix-store-analysis/blob/master/nix-analyze-rootlike
   - https://github.com/deepfire/nix-store-analysis/blob/master/nix-correlate-rootlike-to-current-userenv
   - https://github.com/deepfire/nix-store-analysis/blob/master/nix-correlate-rootlike-to-system

The basic idea is to take a store path, and correlate its referrer
closure with the "leaf set" of store paths, where "leaf set" consists
of:
   - system packages:   nix-store --query --references /nix/var/nix/profiles/system
   - user packages:     nix-env --query --installed --out-path

As it can be seen, there are three glibc and two gcc store paths that
are obviously involved, yet inexplicable -- given the above model, and
the contents of the "About the package zoo" section below.

                          *       *       *

Probing a simple case
=====================

Looking at the simplest case (the glibc with smallest --referrers-closure) provides the following picture:

[deepfire at andromedae:~]$ nix-store --query --referrers-closure /nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
/nix/store/62n981f02b56wjqfdq00pq706k11xz4d-glibc-2.21
/nix/store/5m6i1h71xp6r7k381hrsv5qwn3s6b93h-libXau-1.0.8
/nix/store/kx1l6yis70h9sly7cs4b95jq0j8yxjqr-libXdmcp-1.1.2
/nix/store/bxsi9xrrfc0qw3ndys83rppwqxbn33ma-libxcb-1.11.1
/nix/store/62bmpi8kll9kj8il89kdaddvzib3r4pm-libX11-1.6.3

Why would these be used anywhere on their own?

How are we supposed to understand what is going on?

Should I file a ticket?

-- 
с уважениeм / respectfully / Z poważaniem,
Косырев Сергей


More information about the nix-dev mailing list