Since the answers are hard to understand (to myself) and it took some thinking to understand it ([this comment](https://unix.stackexchange.com/questions/9714/what-is-the-need-for-fakeroot-command-in-linux/52866#comment288153_52866) made me understand it), I'm going to give a hopefully better explanation.

### 1. What happens in fakeroot

Nothing more than what happens with your own user. Absolutely nothing more. If you `fakeroot` (which when called gives you a new shell, like `sudo` would), pretend to do stuff that you needed permission for, and exit, absolutely nothing would happen.

If you think about it, it's a total waste of time. Why would you do stuff that won't actually happen? It's insane. You could have simply not done any of it and there would have been no difference, since there's no trace of it.

Wait a minute...

### 2. The trace of fakeroot

There _could_ be a trace left of `fakeroot`. Let's look at the commands in [MortenSickel's answer](https://unix.stackexchange.com/a/52866/41313) which is pretty nice and deserves an upvote:

    $ fakeroot
    # echo "Wow I have root access" > root.tst
    # ls -l root.tst
    -rw-rw-r-- 1 root root   23 Oct 25 12:13 root.tst
    # ls -l /root
    ls: cannot open directory /root: Permission denied
    # exit
    $ ls -l root.tst
    -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst

At the first glance, it looks like having used `fakeroot` was a total waste of time. In the end, if you hadn't used `fakeroot`, you would have got the same thing.

The subtle thing here is this:

    $ cat root.tst
    Wow I have root access

Which means the content of the file still remembers being a root. You might say not using `fakeroot` would have produced the same results. You are right, this example is too simple.

Let's take another example:

    $ fakeroot
    # touch x
    # touch y
    # chown myuser:myuser x
    # ls -l > listing
    # exit
    $ ls -l
    total 4
    -rw-rw-r-- 1 myuser myuser 152 Jan  7 21:39 listing
    -rw-rw-r-- 1 myuser myuser   0 Jan  7 21:39 x
    -rw-rw-r-- 1 myuser myuser   0 Jan  7 21:39 y
    $ cat listing
    total 0
    -rw-rw-r-- 1 root   root   0 Jan  7 21:39 listing
    -rw-rw-r-- 1 myuser myuser 0 Jan  7 21:39 x
    -rw-rw-r-- 1 root   root   0 Jan  7 21:39 y

Let's see what happened. I pretended to be `root`, which is totally ineffective, and created `x` and `y`. I pretended `x` to belong to `myuser` and `y` to belong to `root`. They actually both belong to `myuser` (as we can see in the end), but I just _pretended_ it to be like that.

Then I created a listing and saved my imagination to a file. Later when I look back at the file, I can see who I imagined the files should be owned by. Again, they are not actually owned by people I imagined, I just simply imagined that.

### 3. So... Why do you want that again?

You may say that I didn't really need to fake being root to create that listing. I could have simply created the listing, then edited it to reflect my imagination. You are right, you didn't need `fakeroot` for that. In fact, knowing that `fakeroot` doesn't actually do anything, you can't have possibly gained any ability you didn't have before.

**But**, and this is what `fakeroot` is all about, editing the listing could be nontrivial. As it is with a package that can be installed on your system, you have a `tar`ed, `gzip`ed, `xz`ed, `bzip2`ed or any other format that is keeping your files together and remembering their permissions and owners. Can you easily modify the compressed file and edit ownership of a file? I don't know about you, but I can't think of a way.

Could there be a tool built that, once everything is compressed, it modifies the compressed file and programmatically edits the ownerships and permissions? Yes there could. So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier.

### 4. Why not just use `sudo`?

First of all, you don't need root privileges to build software and you don't need root privileges to compress them. So if you don't need it, you'd have to really be a Windows user to even think of getting that permission. But sarcasm aside, you may not even have root password.

Besides, let's say you do have root permissions. And let's say you want to pretend that a file should have read access only to the root. So you `sudo`, actually change the file owner and permissions to `root`, you get out of root shell and try to package everything. You fail because now you cannot read the file anymore since you don't have root access. So you have to `sudo` and compress and build the package as root. Effectively, you have to do everything as root.

This is Bad<sup>TM</sup>.

As a packager, you don't need root permissions and you shouldn't get it. When you install a package, you may need to install some file (`A`) as root and that's where you need root permissions.  All `fakeroot` does is to make this possible. It lets the packager list `A` as owned by root for the archiver, so that when the package is decompressed by the user, the archiver demands root permission and creates `A` as owned by root.