APT -fanatics- users, what do you want to see in future APT versions?
I’m going to share my wish-, um TODO list:
What are your thoughts?
An EASY way to list packages installed by the system during distro installation (that is, packages installed automatically) separately from those you have installed manually since that date (ie NOT upgrades, just manual extras). Even adding a blank line between the two groups would do when listing the entire db.
IMO getting rid of “WARNING: apt does not have a stable CLI interface. Use with caution in scripts.” is way overdue.
I would like to see a solver that offers first solutions without removing stuff, but preferring to keep. Mostly during library transitions this is a huge pain unitl all packages are recompiled, but the solver often fails to find the solution (or I couldn’t wait for the 500th solution …).
Another thing which might be already possible, but I haven’t found, is searching packages for version number (updating test packages, large groups of the same version,…)
I would like to see a solver that offers first solutions without removing stuff, but preferring to keep.
I’m looking into building a solver based on z3 or clasp that can support user-defined optimization criteria like the existing aspcud (and other apt-cudf) solver can.
By default, aspcud has the multi-criteria optimization -removed,-changed,-new:
So this should roughly do what you want - if it can find a solution without removals, it would present it as the best choice.
Things get more involved with recommends however - do you want to priorise “no removals” over “no unsat recommends”, or vice versa, or do you want to mix them somehow (like say, a Recommends has the same cost as 5 removals). For a general purpose solver, the answer is probably somewhere in between, and we might end up with a mixed criterium and need to tweak the parameters until it produces the most expected results.
Another thing which might be already possible, but I haven’t found, is searching packages for version number (updating test packages, large groups of the same version,…)
you can use apt list ?version(your regex here) or apt-cache show ?version(your regex here) if you need something machine readable starting with apt 2.0
An EASY way to list packages installed by the system during distro installation (that is, packages installed automatically) separately from those you have installed manually since that date (ie NOT upgrades, just manual extras). Even adding a blank line between the two groups would do when listing the entire db.
We don’t store such information, and in our terminology, packages are manually installed if you selected them explicitly (or they were explicitly installed by the initial install; e.g. top-level meta packages), and automatic packages are the additional dependencies they needed.
What I do is run apt-mark minimize-manual regularly - that does the same step as during install - it marks all packages a meta package depends on as automatically installed. This way, only packages not in a metapackage remain manually installed and I can dig into that list with apt-mark showmanual or apt list ?not(?automatic) and investigate.
It needs switches for machine-readable output and probably versioned behavior, so that we can continue to evolve apt without breaking scripts. I have plans for that, but I’m not if we need both or just version our behavior+output.
That’s very useful info, thank you.
I somehow expected that, but a colleague has pointed out — duuh — that a list sorted by date would pretty much fix it, if it was possible to skip those which were upgrades to packages installed at system installation time.
Best is to take a shapshot list at system installation and then diff the package names.
The man page should mention that full-upgrade doesn’t upgrade to another release of the distribution. It’s confusing for some users, see the followups of Oli’s thread at the Ubuntu users mailing list archive.
A history command similar to dnf’s.
The #1 apt-related problem that I see on AskUbuntu is handling Held Broken Packages.
Background: The main use case I see is a new user who unwisely adds multiple unnecessary PPAs while following random bad advice from the wilderness of the internet. Everything seems to work until weeks or months later when they start getting cryptic apt messages. They ignore those messages for a few more weeks or months until they finally drop in to ask.
The typical current prescription is a bit of apt policy digging to identify the non-Ubuntu source of the problem, then to use ppa-purge to remove the source and it’s packages, and finally to re-install those packages from an Ubuntu source.
Many new users don’t have the patience to learn the new concepts and tools; they get frustrated and reinstall.
Here’s today’s classic example: https://askubuntu.com/questions/1247984/
Suggestions:
Many folks don’t understand what the term Held Broken Packages means (they often latch onto broken and think the package is corrupted). I suggest renaming the problem to something more like version conflict (but better than that).
Apt’s package-based version conflict information (“Foo (=1.x) but it is not going to be installed”) suggests two possible improvements:
Improve the solver to provide specific conflict information (“Foo (=1.x) but 1.y is already installed”) in more situations. Reduce the number of times that users encounter the generic “is not going to be installed”
Provide additional source-based conflict information (“Foo (=1.x) from focal-updates cannot be installed because Foo 1.y from sneaky-pete-PPA is already installed”)
The capability, rather like ppa-purge, to list (optionally remove/purge) all packages from a single source and optionally disable/delete that source.
The #2 apt-related problem that I see on AskUbuntu is Confusion About Sources.
Here’s one example:
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/webupd8team/atom/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
We all know that this simply means the PPA hasn’t any Focal packages at all, and should be disabled. But new users don’t know that, and somebody asks a variation on this roughly every day.
Can we refine the message a bit to point new users toward a useful solution? The apt-secure(8) manpage is a bit of a confusing dead end for them, which is why they end up at AskUbuntu.
Alternately, perhaps apt could, with appropriate safeguards, disable the source line itself and append an explanation comment, timestamp, etc.
A related use case occurs where the user doesn’t understand why their spiffy new source doesn’t seem to be installing Foo for them, and they repeat the add-source shell incantations multiple times, winding up with:
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:33 and /etc/apt/sources.list:87
W: Target Packages (main/binary-i386/Packages) is configured multiple times in /etc/apt/sources.list:33 and /etc/apt/sources.list:87
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:33 and /etc/apt/sources.list:87
Most help pages and most helpful individuals give command-line advice rather than GUI steps or advice. In addition, most people who give command-line advice don’t explain the commands they suggest or offer instructions on how a user can look up what the commands do.
Since commands are likely all most users will see, revisiting the naming conventions for some of the apt command options could prevent the repeated need for assistance such users often require when such commands are suggested and misunderstood by the users.
Apparently the “dist-upgrade” option was changed to the “full-upgrade” in an attempt to deal with some of the confusion, but I feel that it’s the “upgrade” part of the options that’s confusing, repeatedly causing users concern that they might unintentionally upgrade their operating system to a newer version. This is an ongoing issue (you can see for yourselves all over the internet), requiring repeated interventions from well-intentioned individuals who feel compelled to step in to explain what the commands do. It’s been going on for quite some time and is likely to continue until something changes.
I’d like to suggest renaming these options this way to make it clear that their actions will be gentler than an actual operating system upgrade:
* “update” to “refresh”
* “upgrade” to “update”
* “full-upgrade” to “full-update”
I would like apt install/apt upgrade to do an apt update automatically, if the downloaded lists files are missing or outdated. This situation tends to crop up every time you boot a LiveCD session, or spawn a Docker image, or launch a new VM with Vagrant.
I don’t think this is confusing. It’s confusing that dist-upgrade does that, but that’s why we renamed it to full-upgrade.
acknowledged.
The message could be better. A better solver should give us better, or let’s say, different error messages like:
Some packages could not be installed due to unsatisfiable dependencies:
A depends on B
B conflicts A
This can be super useful, or super hopeless, but it’s essentially the unsat core a sat solver produces if we give every clause a variable that identifies it (otherwise it would just say A, B; and I think listing the dependencies that conflict with each other, rather than the packages is more helpful).
The message is suboptimal, but it’s the correct one which I guess becomes important if you have repos without Release files. I’m not sure how a better message would look like.
This is not going to happen. Nothing here suggests an upgrade of Ubuntu releases, that’s why we renamed dist-upgrade to full-upgrade in the first place. It’s upgrading packages. If we renamed it like this, everything would break.
This is a huge pet peeve of mine that other package managers, rather than reusing the apt terminology made up their own.
This always annoys me a ton when I use dnf, so I’m just going to say I’m not a huge fan of it.
Something I would like to be able to do is to have the release indices but not the updates one in the docker images we publish, and have apt refuse to install things until the updates indices have been downloaded.
Please do not break working tool.
Take care on
as it is very annoying.
I want apt to have a way to define repos like in dnf, current apt format forces you to specify distro name, focal for example, deb http://ppa.launchpad.net/fish-shell/release-3/ubuntu focal main, and after every distro upgrade your added repos are disabled, and you need to re-add them again, cause apt can’t change distro name in repo lines, which is super annoying. dnf repos works differently metalink=https://mirrors.rpmfusion.org/metalink?repo=free-fedora-source-$releasever&arch=$basearch, distro name is replaced with env variable, which is nice, and after distro update repos does not get disabled, which is awesome.
this is not APTs fault but the update-manager (which is generally changing repo lines in your source.list during upgrades and makes sure all PPAs get disabled to secure that you do not get system libs and binaries from some hacked up PPA version during upgrade).
the problem here is that not all PPAs do/will have the release enabled you are upgrading to (especially if you upgrade early in a new release PPAs will not have picked up the new release yet, not all PPA maintainers do update their PPAs right after a new release and invest the time to fix their packages for new behavior a new released version brings along), which will cause errors … so you can not automatically and blindly enable them after upgrade either, this requires manual intervention and review of the admin of a system.
It’s actually ubuntu-release-upgrader which manages the upgrade process between releases of Ubuntu. Additionally, there is a switch --allow-third-party which will try the upgrade with third party mirrors and repositories (i.e. PPAs). However, has Ogra has said that could create issues with the upgrade process.