[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: disk usage for /usr/lib on bullseye

On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> > man apt
> Which doesn't say what 'apt purge' does without a package name. It says
> 'Performs the requested action on one or more packages specified via
> regex(7), glob(7) or exact match'. It doesn't go on to say what happens
> if you leave that blank.

Yeah, I couldn't find it either.  The apt(8) man page is pretty damned
annoying, in fact.  One must guess and infer like crazy, because it
doesn't come out and *state* all the things that should be stated.

For example, apt(8) says this:

       install, reinstall, remove, purge (apt-get(8))

What does that "apt-get(8)" mean at the end of that line?  Does it mean
that more information on "purge" is to be found in apt-get(8)?  Here's
what apt-get(8) says about it:

           purge is identical to remove except that packages are removed and
           purged (any configuration files are deleted too).

And here's what it says about remove:

           remove is identical to install except that packages are removed
           instead of installed. Note that removing a package leaves its
           configuration files on the system. If a plus sign is appended to
           the package name (with no intervening space), the identified
           package will be installed instead of removed.

Do these things apply to "apt purge" as well?  Maybe.  In any case, it
doesn't tell us what happens when no package names are specified.

Here's another fun little observation: apt(8) does not mention simulate,
dry-run, -s, or any other synonym for a command that one might use to
probe the behavior of the options and actions that are under-documented.
Maybe apt uses the same --dry-run option as apt-get.  Maybe not.
Who knows?  Is it safe to try?  Who knows!!

Maybe I can experiment?  Let's see if "apt purge" is a syntax error:

unicorn:~$ apt purge
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

Rats!  No luck here.  Either "apt purge" is not an error, or the argument
processing and validation happens only after acquiring the lock.

Now we have to tread dangerous waters to find out more information.

unicorn:~$ sudo apt --dry-run
[sudo] password for greg: 
E: Command line option --dry-run is not understood in combination with the other options

OK... that's progress.  It looks like the --dry-run option exists.
So maybe we can use that to avoid destroying our system by trying commands
as root.

unicorn:~$ sudo apt --dry-run purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So... uh... what happened here?  It certainly didn't complain about a
lack of package names.  No error messages.  It didn't appear to *do*
anything, though, other than spend a bunch of time and energy reading
package lists and building dependency trees for no apparent reason.

Just to verify, I *do* have some packages in "rc" state.

unicorn:~$ dpkg -l | grep ^rc
rc  fuse                                                        2.9.9-3                                                      amd64        Filesystem in Userspace
rc  libreoffice-sdbc-firebird                                   1:6.1.5-3+deb10u6                                            amd64        Firebird SDBC driver for LibreOffice
rc  libsensors4:amd64                                           1:3.4.0-4                                                    amd64        library to read temperature/voltage/fan sensors
rc  python                                                      2.7.16-1                                                     amd64        interactive high-level object-oriented language (Python2 version)

So it looks like "apt purge" might not do anything at all.  At least,
in combination with --dry-run it doesn't *say* that it's going to do

If you're braver than I am, you might try it without the --dry-run and
see what happens.  I'm guessing it'll do nothing, but I cannot guarantee
that, and I take no responsibility for any losses or damage.

Reply to: