devsetup1-3  Exercise 3: Software apt Does Not Know About
==========================================================

PART 1: A FILE OUTSIDE apt
--------------------------
    mkdir -p ~/.local/bin
    printf '#!/bin/sh\necho "hello from a hand-made tool"\n' > ~/.local/bin/hello
    chmod +x ~/.local/bin/hello

    ~/.local/bin/hello
    command -v hello
    dpkg -S ~/.local/bin/hello

What you should see:

    hello from a hand-made tool

command -v hello may print nothing. Debian's default login setup adds
~/.local/bin to the PATH only if the directory already existed when you logged
in, so a directory you just created is not on the PATH until you log out and in
again. Running the script by its full path always works. After logging back
in, command -v hello prints /home/yourname/.local/bin/hello.

    dpkg-query: no path found matching pattern /home/yourname/.local/bin/hello

That last message is the point: no Debian package owns the file, so apt's
tools know nothing about it. If you later wanted to remove or update it, you
would have to do that yourself; apt full-upgrade will never touch it.

Clean up:
    rm ~/.local/bin/hello

PART 2: THREE UNFAMILIAR PACKAGES
---------------------------------
    apt-mark showmanual | shuf -n 3
    apt show PACKAGE-NAME

(shuf picks three at random. Pick any three names you do not recognise.)

For each package apt show prints a description and the packages it depends
on. Typical reasons an unfamiliar package is marked manual:
  - The installer or the desktop task selected it as part of a group (for
    example the GNOME desktop or "standard system utilities").
  - It was installed as a recommended companion of something you chose.
  - You installed it in an earlier chapter.

Examples of what you might find: a GNOME component, a font package, a printer
or Bluetooth service, or a language pack. None of them are worth removing
without understanding them first.

A useful follow-up: to see why a package is present, look at what depends on
it with

    apt rdepends --installed PACKAGE-NAME

If a manual package has no obvious purpose and nothing depends on it, it is a
candidate for removal in Chapter 10, once you have a reproducible setup that
proves you can put it back.

WHY THIS WORKS AS AN ANSWER
---------------------------
Part 1 shows the practical test for "did this come from apt?" and why files
outside apt need separate tracking. Part 2 builds the habit of questioning a
list before trusting it, using the tools that describe the package rather than
guessing from its name.