Mechanical train signals used to signal if the next section is clear vs. blocked by another train used to have the arm raised if it was clear and down if not. That was so that if the mechanic would fail in some way the arm would fall down and rest in the "blocked" state rather than in a "clear" state potentially causing huge problems.
I like to think that it is the same here. If the data gets lost, corrupted or whatever we fall back to a safe state: protected from autoremove as manual installed rather than causing havoc. In reality the original implementer might not have thought that far, but he isn't around anymore to ask him… and it isn't really important, is it? Your precived "slowness" might be an out of dated cache. Have you recently run an apt command with root rights? If it is not run as root apt will build the cache in memory only. That cache can also easily be many megabytes big, which can take a while to shuffle into disk cache on a slow spinning disk. Your script might be very fast, but it is also wrong (Auto-Installed is not the only field which can be set there even if for apt its the only one used. Other clients could use other fields and in that case apt would of course also keep the manual entries…) and doesn't even begin to support what apt-mark does. If you want to constructively work on speeding apt in these cases is to look at where the time is lost and optimize those codepaths. Showing off your script-foo is not helping and borderline trolling… after all, I can easily point at a lot of traveling salesperson (well, perhaps not in corona times), but that seems like a very hard problem for computers somehow. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1713219 Title: 'apt-mark showauto' and 'apt show' is slow Status in apt package in Ubuntu: Triaged Bug description: $ time apt-mark showauto >/dev/null real 0m0.587s user 0m0.552s sys 0m0.016s When I run the command first time, it is even much slower. I could do the job in fraction of a time using awk in POSIX shell script: auto_file='/var/lib/apt/extended_states' eval $(apt-config shell auto_file Dir::State::extended_states/f) awk '/^Package:/ { pkg=$2 getline; arch=$2 getline if($2==1) print pkg ":" arch }' "$auto_file" | CL_ALL=C sort -u real 0m0.019s user 0m0.008s sys 0m0.000s That prints architecture for every package and shows entries in slightly different order, though. And the file could be out of date showing packages that are not installed?!? Similarly apt show <pkg> is slow. (It also shows whether a package is manually or automatically installed. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: apt 1.0.1ubuntu2.17 ProcVersionSignature: Ubuntu 4.4.0-92.115~14.04.1-generic 4.4.76 Uname: Linux 4.4.0-92-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.25 Architecture: amd64 CurrentDesktop: XFCE Date: Sat Aug 26 12:59:00 2017 EcryptfsInUse: Yes InstallationDate: Installed on 2014-09-21 (1070 days ago) InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.1) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.cron.daily.apt: [modified] modified.conffile..etc.kernel.postinst.d.apt.auto.removal: [modified] mtime.conffile..etc.cron.daily.apt: 2017-05-03T10:27:27.617839 mtime.conffile..etc.kernel.postinst.d.apt.auto.removal: 2017-06-01T14:39:39.236080 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1713219/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
