Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reuse /run/current-system/sw instead of /run/system-manager #45

Open
bryango opened this issue Oct 5, 2023 · 6 comments
Open

Reuse /run/current-system/sw instead of /run/system-manager #45

bryango opened this issue Oct 5, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@bryango
Copy link
Contributor

bryango commented Oct 5, 2023

Is your feature request related to a problem? Please describe.

I was trying to adapt nixos modules for system-manager and noticed that many of them have hard-coded /run/current-system/sw; see e.g.

One must modify /run/current-system -> /run/system-manager in order to port such modules.

Describe the solution you'd like

Since /run/current-system is not used in a generic non-NixOS system I believe we can simply re-use the path.

Describe alternatives you've considered

  • As mentioned before, rename each /run/current-system -> /run/system-manager module by module.
  • Alternatively, provide an option to symlink /run/current-system -> /run/system-manager when profiles are activated.

Additional context

I am not sure if it's safe to do this. It feels safe to me since system-manager should only be used on non-NixOS so there will not be conflicts. But I don't know.

@bryango bryango added the enhancement New feature or request label Oct 5, 2023
@r-vdp
Copy link
Member

r-vdp commented Oct 5, 2023

I'd prefer doing the symlink and making it optional, so that it can be turned off in case anyone has issues with it.

@bryango
Copy link
Contributor Author

bryango commented Oct 5, 2023

Oh I just noticed that NixOS itself is on the list of supported systems:

system-manager.preActivationAssertions = {
osVersion =
let
supportedIds = [ "nixos" "ubuntu" ];
in
{
enable = !config.system-manager.allowAnyDistro;

So indeed it should be an option that one can toggle on or off.

@sellout
Copy link

sellout commented Sep 18, 2024

To help make modules more portable, is there some attribute that would return /run/current-system/sw in a nixosModule and /run/system-manager on a systemModule? I’d be happy to fix the hardcoding of /run/current-system/sw in nixpkgs if so.

@r-vdp
Copy link
Member

r-vdp commented Sep 18, 2024

I don't think we have that right now, but it would be rather easy to introduce an option for this. It might be a rather hard sell to get that merged into nixpkgs though.

@aanderse
Copy link
Contributor

It might be a rather hard sell to get that merged into nixpkgs though.

i suggest there is prior art for a change like this

additionally, with more and more nix based systems popping up i think this is a good idea to have an option for this at least as an internal option

tangentially related... seems like a PR replacing all instances of /run/wrappers/bin in nixpkgs/nixos with config.security.wrapperDir is a good idea... we might even consider setting security.wrapperDir = "/sbin"; on system-manager 🤷‍♂️


To help make modules more portable, is there some attribute that would return /run/current-system/sw in a nixosModule and /run/system-manager on a systemModule? I’d be happy to fix the hardcoding of /run/current-system/sw in nixpkgs if so.

please do, and if you don't mind i would love a ping on that PR

@Meliketoaste
Copy link

In nixpkgs they also use environment.pathsToLink this seems relevant but Im dumb.

pathsToLink = lib.mkOption {
        type = lib.types.listOf lib.types.str;
        # Note: We need `/lib' to be among `pathsToLink' for NSS modules
        # to work.
        default = [];
        example = ["/"];
        description = "List of directories to be symlinked in {file}`/run/current-system/sw`.";
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants