Keeping a system lean - GNU/Linux
Users browsing this thread: 2 Guest(s)
|
|||
Hey all,
When you are doing modifications and dev work, do you keep your systems lean in terms of packages? Say you wanted to build a package from source, do you install its dependencies for this build, or was it already installed from a previous build? Do you have another machine that you do the builds on and then transfer the binaries across? I currently have a persistent docker container that I use that is base ubuntu 16.04 for just this reason. It bind-mounts my projects folder and I do all my compiling/building of sources from here, but do all the coding from my main machine. As my config files are all on the host. This way when I do my updates, it's not clogged up with dev libraries and tools and things. Anyone else have anything similar they do or any tips? |
|||
|
|||
Refrain from using unnecessarily bloated operating systems like GNU/Linux. Helps a lot.
-- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
suggested alternative?
windows, of course. |
|||
|
|||
Still less bloated than GNU/Linux. Other than that, there are more than just two systems available.
-- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
|
|||
|
|||
I fail to see how using a different operating system will improve the way you handle "one-time" dependencies. You're not providing any real answer here.
The easiest way I found to do this is to use a chroot build, and install the deps in this chroot prior to building. This way I can make sure I include all the dependencies for my builds (I don't do that way often though) |
|||
|
|||
(22-02-2017, 08:37 PM)robotchaos Wrote: Anyone else have anything similar they do or any tips?Sometimes putting the questions into other words offer some insights. So if I understood correctly you are doing this: * Downloading the source of a program * Using the package manager to install the dependencies * Building and installing the program * Remove the uneeded dependencies (that's the step you want help with) If there was a way to tell your package manager that those packages are installed "as-deps-only-for-build" to something else it would solve the issue, as most package managers have a way to list un-wanted dependencies. I'm falling short on options here. EDIT: As others said, the port system of most BSDs does that nicely. |
|||
|
|||
(23-02-2017, 07:55 AM)venam Wrote: * Remove the uneeded dependencies (that's the step you want help with) FYI:
-- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
(23-02-2017, 08:46 AM)jkl Wrote: FYI: Does it only work for ports installed using pkgin|pkg_add|pkg, or you have a way to install anything as "build-only deps", so then can be removed later? |
|||
|
|||
Installing ports - including dependency ports - usually registers them as installed packages. At least on FreeBSD, I can pkg delete ports I installed via portmaster [port].
-- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
I have never used a ports system, but does it do any of that automatically? It can't know that I'm done using the dep. So I need to manually run clean-up correct?
I'm not opposed to a clean-up process, just trying to figure out a clean way to have minimal updates. So far I've settled on a container, much like a chroot build system. I have my runtime OS that then only does updates on required packages, nothing superfluous. My build container then keeps all the deps installed permanently, and they get updated when I run system updates. I'm not overly concerned with the build container becoming bloated. I think I'm just over-complicating it... As I tend to do. |
|||
|
|||
the only way to keep a system lean is by using plan 9
this is a proven fact. |
|||
|
|||
|
|||
Aha. The saga continues. I started using the nix package manager for this, which has helped tremendously. I am also in the midst of standing up my own hydra server to use as a nix-channel.
|
|||