7 ms·

I loved the idea (git everything!) until I read this: "How do I remove a package and all of its dependencies? [...] The package manager does not do recursive d

I loved the idea (git everything!) until I read this: "How do I remove a package and all of its dependencies? [...] The package manager does not do recursive dependency removal on removal of a package. This error-prone automation will not be added to the package manager. "

pampa 6y ago
This might seem like a limitation. But you can provide a base system with a toolchain & xorg with known dependencies and a limited set of packages (like a BSD base system). Then for every big and complex app clone that base system and build the app in a chroot/sandbox or container. That way you get the app and dont pollute the base system and uninstalling is just rm -rf On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind.
- stargaz3r 6y ago
  >On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind. That's not true at all. See Nix package manager (and NixOS the distro).
  - pampa 6y ago
    nix is more like installing every package in its own chroot, with a few optimizations. not your starnard linux package manager
    - danieldk 6y ago
      That's too much of a simplification. In NixOS you still have global configuration files, such as /etc/fstab. However, they are symlinks to Nix store paths that are associated with the current generation. $ realpath /etc/fstab /nix/store/06k708q78zxw8922rrrc8mmp5gbin4am-etc-fstab However, NixOS installations can also end up accumulating configuration and state files that stick around when they are not defined declaratively. E.g. if you enable ssh, host keys are generated in /etc/ssh. Even if you disable ssh, these files will stick around. You can avoid such accidental state [1], since NixOS will happily boot from a filesystem with just /boot and /nix and reconstruct the rest upon system activation. But it is quite a bit of work, since you need to manually specify what state you want to preserve (e.g. SSH host key files). Also, it currently does not work nicely with some systemd units that barf out if you make /var/run entries symlinks. [1] https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings
      - edraferi 6y ago
        I’m just getting started with Nix, with the explicit goal of making my entire system defined in a private , remote git repo. I want to be able to rapidly re-provision my entire user environment on a new machine, including applications, preferences, etc. For the moment I’m doing this on MacOS with the nix package manager. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed. My current hurdle is exactly the topic of this thread: non-binary configs. For example, what am I supposed to do with .zprofile? I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations. I’m concerned that might cause problems with MacOS system ZSH. I can probably fix that with a custom login shell? Anyway it’s fun, but complicated and diversely documented. Gonna take a while to sort it all out.
        danieldk 6y ago
        My current hurdle is exactly the topic of this thread: non-binary configs. For example, what am I supposed to do with .zprofile? I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations. I’m concerned that might cause problems with MacOS system ZSH. I can probably fix that with a custom login shell? I use both NixOS and macOS. You can take two routes: 1. you can continue using Apple's /bin/zsh and just use a .zprofile generated using Nix (e.g. home-manager). Generally, the differences between zsh versions are not that large and it just works. This is what I have been doing with my Mac. 2. You could change your shell, either system-wide, or just for Terminal.app to ~/.nix-profile/bin/zsh. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed. If you have some leftover hardware, try it! NixOS is a different experience altogether and cannot be paralleled by Nix on macOS or a Linux distribution. Being able to declaratively define your whole system is insanely cool and powerful. Fully reproducible machines. Also, you can try out stuff without any harm. Just switch back to the previous working generation (or try the configuration in a VM with nixos-rebuild build-vm) if you are not happy.
        chriswarbo 6y ago
  - danieldk 6y ago
    By and large yes. However, even on NixOS there can be various leftovers in the form of state files in /var and configuration files in /etc (outside the majority, which are managed through Nix). Unless you nuke most of the root filesystem on every boot [1]. [1] https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings
- nerdponx 6y ago
  Apt autoremove seems to do a pretty decent job.
  - CameronNemo 6y ago
    especially when you pass --purge
- t0astbread 6y ago
  Isn't this basically what Docker is for?
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - dicknuckle 6y ago
    Yes in that it's container tech, but for servers. Snap is the equivalent for desktop. Both have their merits.
- throwaway023421 6y ago
  > On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind. Not at all. Apt has been able to remove everything for the last 20 years.
  - chmod775 6y ago
    > Not at all. Apt has been able to remove everything for the last 20 years. Not really. It can remove configuration files etc. it knows about, but it can't know about files later created by the application itself.
    - nerdponx 6y ago
      I'd say that's either 1) outside the scope of the package manager, or 2) mostly-solvable as long as your package manager allows you to specify "extra files created by the application that I do not install but I will want to uninstall." That's also not what's being asked for here. The basic request is this: track which packages were manually vs automatically installed, and give the user the ability to remove automatically-installed orphans whose manually-installed reverse-dependencies are no longer installed. This is what APT does and it works fine 99% of the time.
    - flukus 6y ago
      Isn't that a feature? Should my settings be cleared if I uninstall a program and reinstall it later? Should all my libre office documents disappear when I uninstall libre office?
globular-toast 6y ago
All of Gentoo's packages are in git and it does support recursive removal: https://github.com/gentoo/gentoo https://github.com/gentoo/gentoo
- KitDuncan 6y ago
  Also Void and xbps.
unixhero 6y ago
Removal is something I've used checkinstall for in the past. Always worked perfectly.
wchar_t 6y ago
Well, then again, many other package managers don't either. For instance XBPS and Pacman. EDIT: I'm wrong, see below.
- natrys 6y ago
  But they do? (e.g. xbps-remove -R/--recursive <pkgname>)
- Boulth 6y ago
  Pacman can remove dependencies that are not used: https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Removing_unused_packages_(orphans) https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#... This is explicit rather than implicit but it works even on one package.
- vinay427 6y ago
  From the ArchWiki: > To remove a package and its dependencies which are not required by any other installed package: > # pacman -Rs package_name > To remove a package, its dependencies and all the packages that depend on the target package: > # pacman -Rsc package_name
jllaneras 6y ago
Instead, the workflow is to remove the single package and then look at the output of the 'kiss-orphans' command to see what can now be removed. This command will list all packages which have no relationship with other packages, otherwise known as orphans. This list may include Firefox and other "end" software so a brain is required when parsing the list. You'll come to learn the relationships between packages and their dependencies and this will eventually become effortless. https://k1ss.org/faq https://k1ss.org/faq
skookum-skuad 6y ago
Yuck. The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages and GCing non-leaf packages. This pattern of "only one global package for everything" is failure. Too often, naïve designers will just cut things because they just don't understand them or copy & paste because they don't understand what failures exist and what solutions do/alternatives could exist. Habitat (hab), nix, and others IIRC do SxS package mgmt. Everything Should Be Made as Simple as Possible, But Not Simpler - possibly paraphrasing Einstein
- enriquto 6y ago
  > The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages (...) Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter of packages written in scripting languages.
  - catern 6y ago
    Static binaries still have dependencies, they just embed them all into one file. That's not generically possible - as the most trivial example, consider a bash script which runs other executables. If you're trying to solve this problem, you need to actually solve it for all real cases; otherwise your solution breaks down and you're back where you started, in dependency hell.
    - burpsnard 6y ago
      This: perl ..
      - mst 6y ago
        App::FatPacker will turn your (pure perl) script and its dependencies into a single file for deployment. App::staticperl will build a static binary with the perl+C dependencies built in. A lot of the time, it's better to use a plenv + Carton, mind, but if you want a single file for deployment, that's a solved problem in perl land too and has been for years.
jedahan 6y ago
I made my own 'autoremove' in about 15 minutes for kiss. Its up in my repo https://github.com/jedahan/kiss-repo https://github.com/jedahan/kiss-repo , and relies on having a package with all your system targets (in my case, named after my hostname) as dependencies: while kiss orphans | grep -qv $HOSTNAME; do kiss remove `kiss orphans | grep -v $HOSTNAME | tr '\n' ' '` done This was much easier to implement in kiss than other package manager extensions in previous distros I've maintained packges for (gentoo, exherbo, arch, debian).
- majewsky 6y ago
  sudo pacman -Rns $(pacman -Qqdtt) Done.
carapace 6y ago
FWIW I'm thinking: Step 1, Install Nix (or Guix.)
- m463 6y ago
  that sounds reasonable (and a unixy solution - combine good individual tools into a better whole)

pampa 6y ago

This might seem like a limitation. But you can provide a base system with a toolchain & xorg with known dependencies and a limited set of packages (like a BSD base system). Then for every big and complex app clone that base system and build the app in a chroot/sandbox or container. That way you get the app and dont pollute the base system and uninstalling is just rm -rf On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind.

stargaz3r 6y ago
>On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind. That's not true at all. See Nix package manager (and NixOS the distro).
- pampa 6y ago
  nix is more like installing every package in its own chroot, with a few optimizations. not your starnard linux package manager
  - danieldk 6y ago
    That's too much of a simplification. In NixOS you still have global configuration files, such as /etc/fstab. However, they are symlinks to Nix store paths that are associated with the current generation. $ realpath /etc/fstab /nix/store/06k708q78zxw8922rrrc8mmp5gbin4am-etc-fstab However, NixOS installations can also end up accumulating configuration and state files that stick around when they are not defined declaratively. E.g. if you enable ssh, host keys are generated in /etc/ssh. Even if you disable ssh, these files will stick around. You can avoid such accidental state [1], since NixOS will happily boot from a filesystem with just /boot and /nix and reconstruct the rest upon system activation. But it is quite a bit of work, since you need to manually specify what state you want to preserve (e.g. SSH host key files). Also, it currently does not work nicely with some systemd units that barf out if you make /var/run entries symlinks. [1] https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings
    - edraferi 6y ago
      I’m just getting started with Nix, with the explicit goal of making my entire system defined in a private , remote git repo. I want to be able to rapidly re-provision my entire user environment on a new machine, including applications, preferences, etc. For the moment I’m doing this on MacOS with the nix package manager. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed. My current hurdle is exactly the topic of this thread: non-binary configs. For example, what am I supposed to do with .zprofile? I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations. I’m concerned that might cause problems with MacOS system ZSH. I can probably fix that with a custom login shell? Anyway it’s fun, but complicated and diversely documented. Gonna take a while to sort it all out.
      - danieldk 6y ago
        My current hurdle is exactly the topic of this thread: non-binary configs. For example, what am I supposed to do with .zprofile? I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations. I’m concerned that might cause problems with MacOS system ZSH. I can probably fix that with a custom login shell? I use both NixOS and macOS. You can take two routes: 1. you can continue using Apple's /bin/zsh and just use a .zprofile generated using Nix (e.g. home-manager). Generally, the differences between zsh versions are not that large and it just works. This is what I have been doing with my Mac. 2. You could change your shell, either system-wide, or just for Terminal.app to ~/.nix-profile/bin/zsh. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed. If you have some leftover hardware, try it! NixOS is a different experience altogether and cannot be paralleled by Nix on macOS or a Linux distribution. Being able to declaratively define your whole system is insanely cool and powerful. Fully reproducible machines. Also, you can try out stuff without any harm. Just switch back to the previous working generation (or try the configuration in a VM with nixos-rebuild build-vm) if you are not happy.
      - chriswarbo 6y ago
- danieldk 6y ago
  By and large yes. However, even on NixOS there can be various leftovers in the form of state files in /var and configuration files in /etc (outside the majority, which are managed through Nix). Unless you nuke most of the root filesystem on every boot [1]. [1] https://grahamc.com/blog/erase-your-darlings https://grahamc.com/blog/erase-your-darlings
nerdponx 6y ago
Apt autoremove seems to do a pretty decent job.
- CameronNemo 6y ago
  especially when you pass --purge
t0astbread 6y ago
Isn't this basically what Docker is for?
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- dicknuckle 6y ago
  Yes in that it's container tech, but for servers. Snap is the equivalent for desktop. Both have their merits.
throwaway023421 6y ago
> On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind. Not at all. Apt has been able to remove everything for the last 20 years.
- chmod775 6y ago
  > Not at all. Apt has been able to remove everything for the last 20 years. Not really. It can remove configuration files etc. it knows about, but it can't know about files later created by the application itself.
  - nerdponx 6y ago
    I'd say that's either 1) outside the scope of the package manager, or 2) mostly-solvable as long as your package manager allows you to specify "extra files created by the application that I do not install but I will want to uninstall." That's also not what's being asked for here. The basic request is this: track which packages were manually vs automatically installed, and give the user the ability to remove automatically-installed orphans whose manually-installed reverse-dependencies are no longer installed. This is what APT does and it works fine 99% of the time.
  - flukus 6y ago
    Isn't that a feature? Should my settings be cleared if I uninstall a program and reinstall it later? Should all my libre office documents disappear when I uninstall libre office?

globular-toast 6y ago

All of Gentoo's packages are in git and it does support recursive removal: https://github.com/gentoo/gentoo https://github.com/gentoo/gentoo

KitDuncan 6y ago
Also Void and xbps.

unixhero 6y ago

Removal is something I've used checkinstall for in the past. Always worked perfectly.

wchar_t 6y ago

Well, then again, many other package managers don't either. For instance XBPS and Pacman. EDIT: I'm wrong, see below.

natrys 6y ago
But they do? (e.g. xbps-remove -R/--recursive <pkgname>)
Boulth 6y ago
Pacman can remove dependencies that are not used: https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Removing_unused_packages_(orphans) https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#... This is explicit rather than implicit but it works even on one package.
vinay427 6y ago
From the ArchWiki: > To remove a package and its dependencies which are not required by any other installed package: > # pacman -Rs package_name > To remove a package, its dependencies and all the packages that depend on the target package: > # pacman -Rsc package_name

jllaneras 6y ago

Instead, the workflow is to remove the single package and then look at the output of the 'kiss-orphans' command to see what can now be removed. This command will list all packages which have no relationship with other packages, otherwise known as orphans. This list may include Firefox and other "end" software so a brain is required when parsing the list. You'll come to learn the relationships between packages and their dependencies and this will eventually become effortless. https://k1ss.org/faq https://k1ss.org/faq

skookum-skuad 6y ago

Yuck. The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages and GCing non-leaf packages. This pattern of "only one global package for everything" is failure. Too often, naïve designers will just cut things because they just don't understand them or copy & paste because they don't understand what failures exist and what solutions do/alternatives could exist. Habitat (hab), nix, and others IIRC do SxS package mgmt. Everything Should Be Made as Simple as Possible, But Not Simpler - possibly paraphrasing Einstein

enriquto 6y ago
> The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages (...) Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter of packages written in scripting languages.
- catern 6y ago
  Static binaries still have dependencies, they just embed them all into one file. That's not generically possible - as the most trivial example, consider a bash script which runs other executables. If you're trying to solve this problem, you need to actually solve it for all real cases; otherwise your solution breaks down and you're back where you started, in dependency hell.
  - burpsnard 6y ago
    This: perl ..
    - mst 6y ago
      App::FatPacker will turn your (pure perl) script and its dependencies into a single file for deployment. App::staticperl will build a static binary with the perl+C dependencies built in. A lot of the time, it's better to use a plenv + Carton, mind, but if you want a single file for deployment, that's a solved problem in perl land too and has been for years.

jedahan 6y ago

I made my own 'autoremove' in about 15 minutes for kiss. Its up in my repo https://github.com/jedahan/kiss-repo https://github.com/jedahan/kiss-repo , and relies on having a package with all your system targets (in my case, named after my hostname) as dependencies: while kiss orphans | grep -qv $HOSTNAME; do kiss remove `kiss orphans | grep -v $HOSTNAME | tr '\n' ' '` done This was much easier to implement in kiss than other package manager extensions in previous distros I've maintained packges for (gentoo, exherbo, arch, debian).

majewsky 6y ago
sudo pacman -Rns $(pacman -Qqdtt) Done.

carapace 6y ago

FWIW I'm thinking: Step 1, Install Nix (or Guix.)

m463 6y ago
that sounds reasonable (and a unixy solution - combine good individual tools into a better whole)