Scope of project and configuration management? #51
Replies: 2 comments 4 replies
-
Thanks for your post!
It is unfortunately out of scope. I would like to follow the basic unix principle "do one thing and do it well".
That should in principle already be possible. This repo holds three crates.
I have a personal dotfile manager that isn't public, where I deploy configs on the actual hostname. Intuitively, I would assume that once you look at what hardware is present, your project's complexity will go through the roof.
Here I started to think that what you actually want is the Nix package manager. It is in principle possible to deploy this to other distributions if your employer requires Debian. I have decided that this is not for me, but have you checked whether this could fit your needs? |
Beta Was this translation helpful? Give feedback.
-
If I want to support this in general yes. I was rather thinking providing a list of found PCI devices etc to the user and let them script what is relevant. E.g. from my asysconf configuration I have: vga_controller="$(lspci | grep -E '3D |VGA ')"
if grep -q NVIDIA <<< "$vga_controller"; then
CUST_GPU_NVIDIA=1
fi
if grep -q Intel <<< "$vga_controller"; then
CUST_GPU_INTEL=1
fi
if grep -q "Advanced Micro Devices" <<< "$vga_controller"; then
CUST_GPU_AMD=1
fi So my plan is enabling the user to write the checks they want/need.
Yes, kind of. I use and like Arch myself, and for work we use Ubuntu for dev environment (we build software for embedded, so that targets a yocto sysroot). Unfortunately when I looked at Nix there was a lot of complexity that didn't seem to be what I want. I don't even really care about a declarative config, I'm perfectly happy having an imperative or rust-like language (rhai?) generate a set of operations to perform (packages that should be installed, config files that should differ from the standard ones, ...) and then be able to apply that. This is what aconfmgr I mentioned above does. It is written in bash (not the language I would choose myself for this, but it works just fine in practice). If I make this project myself I imagine a rust core that deals with discovering current system state (installed packages, changed files) as well as applying the changes to match the wanted state. What changes are wanted is to be determined by an embedded scripting language of some sort (rhai? typescript? python?) that gets called with info on current system state. There is a bit of back and forth: ignored paths affects what gets scanned for example (so I will likely make it more structured than aconfmgr, which much parse the entire config first before scanning system state). I initially envisioned having completely separate configs for arch and debian, but some things would be common (how to patch /etc/inputrc won't be distro specific for example), so maybe there is value in coming up with a decent way to have a shared section and distro specific sections. Food for thought. EDIT: Oh and another reason for Debian support is Raspberry Pis. I have a few of them. Trying to remember to set up certain things the same of all of them is a pain. |
Beta Was this translation helpful? Give feedback.
-
Background
I have been using (mostly happily) aconfmgr to manage installed packages and setting files on my Arch Linux machines.
However I do have to use Debian/Ubuntu based distros at work. This naturally led me to consider how hard it would be to write it myself to add optional multi-distro support, if I would rewrite it in Rust, etc.
As part of searching I came across this crate, which seems to solve some of what I want (the package management bit).
Actual question
Is full on system package and config management something you are interested in/planning on doing for pacdef? Or is it out of scope? If it is out of scope, is it possible to structure things such that code reuse of a public API is possible?
As I see it, what I'm interested in can be split into multiple logical steps, some of which are missing:
One nice thing with aconfmgr is that it can also save the system to your config file (in that case it puts it in a 99-unsoeted.sh file). This is far better than something like ansible, which just manages the things you told it to, instead of trying to capture the entire system state. This is also something I would want.
(I'm under no illusion that I could use the same config file patches on Debian and Arch, but it be nice to have uniform tooling, and some things such as patching nanorc could be reused.)
Beta Was this translation helpful? Give feedback.
All reactions