# Monorepos don't map to our social structure

**URL:** https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162
**Category:** Development
**Created:** [April 26, 2024, 3:49am UTC](https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162 "2024-04-26T03:49:18Z")
**Posts on this page:** 1
**Showing post:** 5

<div class="post-metadata">

### Author: ![amjoseph](https://discourse.nixos.org/user_avatar/discourse.nixos.org/amjoseph/32/28378_2.png) [@amjoseph](https://discourse.nixos.org/u/amjoseph)
#### Post date: [April 26, 2024, 12:05pm UTC](https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162/5 "2024-04-26T12:05:21Z")

</div>

> [@pca006132](#):
>
> Moving away from a monorepo also brings the problem of efficiency, trust

This is a red herring; Linux isn’t a monorepo and they don’t have this vague “problem of trust” that you allude to. And after the XZ debacle I think the whole “it’s on github so I can trust it” myth is dead too.

The real obstacle is that desynchronized development, like kerneldev uses, requires conscious effort. You have to adjust your development style to deliberately avoid things that will cause merge conflicts. Right now nixpkgs interleaves version bumps with (sometimes OCD-driven) treewide style changes, which makes anything other than “merge as quickly as you can” miserable.

> [@Major Nixpkgs contributor leaving](https://discourse.nixos.org/t/major-nixpkgs-contributor-leaving/44053/39):
>
> re monorepo I’ll just link [Contributor retention - #42 by Ma27](https://discourse.nixos.org/t/contributor-retention/12412/42)
> 
> > Due to Nix’s purely functional model (and only an experimental CAS implementation), changes in core packages such as openssl, glibc and friends will basically cause a full rebuild

It doesn’t have to be like this.

Without any changes to Nix, there is an architecture which avoids rebuilds when a dynamically linked dependency changes, _so long as the symbol table of the .so file does not change_ (i.e. set all symbols to zero length) which covers basically any change other than a version bump. This is different from both `pkgs.replaceDependency` and also from guix’s grafts.

This does not require content-addressed derivations. However it _does_ require a strict hygenic separation between the `buildPlatform` and the `hostPlatform` essentially equivalent to cross-by-default.

Both of the above changes (development style and symtab-hash dependencies) have an incentive problem. They are positive changes for nixpkgs in the long run, but since they make it easier to maintain competing forks those who manage the monorepo are disincentivized to adopt them. Also, both changes require a substantial amount of real work.

---

_[View the full topic](https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162)._