5 ms·

> The most striking difference to the classic APT solver is that solver3 always keeps manually installed packages around, it never offers to remove them. Y'kno

> The most striking difference to the classic APT solver is that solver3 always keeps manually installed packages around, it never offers to remove them. Y'know, when you put it like that it does seem rather obvious, doesn't it? Principle of least surprise and all that. Edit: To be clear, not knocking anyone for it; hindsight is 20/20 and I've never written a dependency solving algorithm so I'm in no position to judge.

giancarlostoro 3y ago
I love when this happens when I find a new product, I think to myself would be even better if they did this really simple tweak. Then a week or two later they do the same exact change. Apt probably moves a little slower on “big” changes, since theres many implications. I cant even imagine the number of obscure scripts that something like this breaks because the output and behavior is slightly off somehow.
layer8 3y ago
It’s not that clearcut, because sometimes you forget all the packages you installed manually over the years and aren’t using anymore, and it can make sense to be offered to remove one when it helps resolving a conflict with a newer package that you actually want to use now.
- yjftsjthsd-h 3y ago
  Yeah, I've hit that exact situation on one of my machines running Void Linux (so obviously completely different package manager). I personally think it's best to tell the user that it can't make the given constraints work and suggest which package(s) are the problem, and then if the user is willing to part with them then they can `apt remove foo && apt upgrade` or w/e (which is more or less my experience of how Void's xbps does it).
- inopinatus 3y ago
  The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. Corollary: make it easy on yourself: mount /home separately (and maybe /var too), and keep /etc in scm.
  - josephg 3y ago
    > The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. I wish there was more rigor (and testing) with this sort of thing. Generally systems should have the invariant that “install old” + “upgrade” == “install new”. This property can be fuzz tested with a bit of work - just make an automated distribution installer, install random sets of packages (or all of them), upgrade and see if the files all match. /etc makes this harder, since you’d want to migrate old configuration files rather than resetting configuration to the defaults. But I feel like this should be way more reliable in general. And people want that reliability - if the popularity of docker and nix are anything to go by.
    - LtWorf 3y ago
      In theory yes, but this hits with the fact that defaults change. For example a new system won't have pulseaudio, but it won't be removed and replaced automatically because that would be potentially disruptive to existing users.
    - inopinatus 3y ago
      Alas that many packages will not upgrade conffiles gracefully when their structure/semantics change, and many are beyond the ability of any package manager's built-in diffing tools to apprehend. That is why I place /etc under scm for long-lived hosts, because what happens next instead looks an awful lot like doing a conflicted three-way code merge following a breaking-change vendor release. The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd.
      - pxc 3y ago
        related: https://etckeeper.branchable.com/ https://etckeeper.branchable.com/ > The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd. I think by the time I started with it, NixOS was already on systems, but reportedly that transition went off without a hitch. Before the transition, NixOS configs were in charge of generating OpenRC scripts or whatever, then afterwards the same configs generated systemd units instead. When the system has total control over the config files like that you get to bypass certain challenges! You might notice that the old announcement for that feature includes no special care other than the requisite reboot to change init systems: https://web.archive.org/web/20200423143059/https://releases.nixos.org/nix-dev/2013-January/010482.html https://web.archive.org/web/20200423143059/https://releases....
- josephg 3y ago
  I don’t know if other distributions do this, but I quite like gentoo’s “world” file. Its a text file listing all the manually installed packages. Everything in the list is pinned in the dependency tree, and kept up to date when you “emerge update”. I constantly install random stuff for random projects then forget about it. The world list lets me easily do spring cleaning. I’ll scroll through the list, delete everything I don’t recognise and let the package manager auto remove unused stuff. I think nix has something similar. I wish Debian/ubuntu had something like that - maybe it does - but I’ve never figured it out.
  - deleted 3y ago
    [deleted]
  - skrause 3y ago
    Debian has debfoster.
  - stock_toaster 3y ago
    Alpine has a similar /etc/apk/world file. Further, you can edit this file and then `apk fix` will update the system to reflect any changes.
  - adgjlsfhk1 3y ago
    I think OSes really should take inspiration from the newest generation of programming languages here. Rust and Julia (as well as a few others) do a lot better than the OS. Features like environments (e.g. for installing per user packages), and a clean separation of a project and an environment would be very nice.
    - yjftsjthsd-h 3y ago
      I hesitate to say it because it comes up in approximately every single conversation about package management, but... NixOS does all of those things. Whole list of packages in configuration.nix, whole of /etc encoded into configuration.nix, flakes let you pin everything, (therefore) it's trivial to check the whole OS config (packages, versions, configurations) into version control, home manager lets you do all this per-user (or you can do it in the system-wide configuration.nix if you really want), and you can drop a flake.nix+flake.lock in any project directory and scope things that way.
- dylan-m 3y ago
  This is one of my favourite things about Fedora Silverblue and rpm-ostree. If I run `rpm-ostree status`, I get a list of all the packages I’ve installed or removed compared to the base image. Makes it really easy to keep track of what’s different in my system compared to the current default.
- o11c 3y ago
  On Debian-derived systems, the list can be found with: aptitude search '?installed ?not(?automatic)' (or filter with that within the program, etc.) There's probably a way without aptitude, but using Debian without aptitude is like riding a bicycle without gears.
deleted 3y ago
[deleted]

giancarlostoro 3y ago

I love when this happens when I find a new product, I think to myself would be even better if they did this really simple tweak. Then a week or two later they do the same exact change. Apt probably moves a little slower on “big” changes, since theres many implications. I cant even imagine the number of obscure scripts that something like this breaks because the output and behavior is slightly off somehow.

layer8 3y ago

It’s not that clearcut, because sometimes you forget all the packages you installed manually over the years and aren’t using anymore, and it can make sense to be offered to remove one when it helps resolving a conflict with a newer package that you actually want to use now.

yjftsjthsd-h 3y ago
Yeah, I've hit that exact situation on one of my machines running Void Linux (so obviously completely different package manager). I personally think it's best to tell the user that it can't make the given constraints work and suggest which package(s) are the problem, and then if the user is willing to part with them then they can `apt remove foo && apt upgrade` or w/e (which is more or less my experience of how Void's xbps does it).
inopinatus 3y ago
The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. Corollary: make it easy on yourself: mount /home separately (and maybe /var too), and keep /etc in scm.
- josephg 3y ago
  > The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. I wish there was more rigor (and testing) with this sort of thing. Generally systems should have the invariant that “install old” + “upgrade” == “install new”. This property can be fuzz tested with a bit of work - just make an automated distribution installer, install random sets of packages (or all of them), upgrade and see if the files all match. /etc makes this harder, since you’d want to migrate old configuration files rather than resetting configuration to the defaults. But I feel like this should be way more reliable in general. And people want that reliability - if the popularity of docker and nix are anything to go by.
  - LtWorf 3y ago
    In theory yes, but this hits with the fact that defaults change. For example a new system won't have pulseaudio, but it won't be removed and replaced automatically because that would be potentially disruptive to existing users.
  - inopinatus 3y ago
    Alas that many packages will not upgrade conffiles gracefully when their structure/semantics change, and many are beyond the ability of any package manager's built-in diffing tools to apprehend. That is why I place /etc under scm for long-lived hosts, because what happens next instead looks an awful lot like doing a conflicted three-way code merge following a breaking-change vendor release. The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd.
    - pxc 3y ago
      related: https://etckeeper.branchable.com/ https://etckeeper.branchable.com/ > The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd. I think by the time I started with it, NixOS was already on systems, but reportedly that transition went off without a hitch. Before the transition, NixOS configs were in charge of generating OpenRC scripts or whatever, then afterwards the same configs generated systemd units instead. When the system has total control over the config files like that you get to bypass certain challenges! You might notice that the old announcement for that feature includes no special care other than the requisite reboot to change init systems: https://web.archive.org/web/20200423143059/https://releases.nixos.org/nix-dev/2013-January/010482.html https://web.archive.org/web/20200423143059/https://releases....
josephg 3y ago
I don’t know if other distributions do this, but I quite like gentoo’s “world” file. Its a text file listing all the manually installed packages. Everything in the list is pinned in the dependency tree, and kept up to date when you “emerge update”. I constantly install random stuff for random projects then forget about it. The world list lets me easily do spring cleaning. I’ll scroll through the list, delete everything I don’t recognise and let the package manager auto remove unused stuff. I think nix has something similar. I wish Debian/ubuntu had something like that - maybe it does - but I’ve never figured it out.
- deleted 3y ago
  [deleted]
- skrause 3y ago
  Debian has debfoster.
- stock_toaster 3y ago
  Alpine has a similar /etc/apk/world file. Further, you can edit this file and then `apk fix` will update the system to reflect any changes.
- adgjlsfhk1 3y ago
  I think OSes really should take inspiration from the newest generation of programming languages here. Rust and Julia (as well as a few others) do a lot better than the OS. Features like environments (e.g. for installing per user packages), and a clean separation of a project and an environment would be very nice.
  - yjftsjthsd-h 3y ago
    I hesitate to say it because it comes up in approximately every single conversation about package management, but... NixOS does all of those things. Whole list of packages in configuration.nix, whole of /etc encoded into configuration.nix, flakes let you pin everything, (therefore) it's trivial to check the whole OS config (packages, versions, configurations) into version control, home manager lets you do all this per-user (or you can do it in the system-wide configuration.nix if you really want), and you can drop a flake.nix+flake.lock in any project directory and scope things that way.
dylan-m 3y ago
This is one of my favourite things about Fedora Silverblue and rpm-ostree. If I run `rpm-ostree status`, I get a list of all the packages I’ve installed or removed compared to the base image. Makes it really easy to keep track of what’s different in my system compared to the current default.
o11c 3y ago
On Debian-derived systems, the list can be found with: aptitude search '?installed ?not(?automatic)' (or filter with that within the program, etc.) There's probably a way without aptitude, but using Debian without aptitude is like riding a bicycle without gears.

deleted 3y ago

[deleted]