WHY NOT FAKEROOT?

Previous versions of Wind River Linux used fakeroot. We wrote pseudo because we found that fakeroot didn’t fit our usage patterns very well. Note that these are not necessarily “flaws” with fakeroot; they’re ways in which it didn’t meet our needs, but not necessarily reasons for which it’s a bad fit for the package builds it was designed for. This page attempts to explain why we built a replacement for fakeroot; it is not intended to tell you that you shouldn’t use it. If it’s working, great.

• fakeroot doesn’t really support a persistent database. Sure, it has the ability to dump its internal tables, but this is done only on shutdown, meaning that interruption can lose data.
• fakeroot doesn’t track file paths. This makes it much too easy for the database to become “corrupted” — usually meaning that someone touched/removed/created files outside of the fakeroot environment. While pseudo can’t track them perfectly, it is usually able to at least detect mismatches and report errors.
• fakeroot, by default, reserves System V IPC objects which must be manually cleaned if something prevents the daemon from cleaning them up itself.
• faked needs to be explicitly started and stopped, and if it goes away unexpectedly, Bad Things Happen.

Fundamentally, fakeroot was built to handle the needs of creating package files; it was built for single reasonably short runs after which the data it was tracking don’t matter. Our usage involves large projects with hundreds of packages, which may be actively used for a period of weeks or months. To this end, we designed @pseudo> rather differently:

1. The database is maintained as an sqlite3 database, which is kept on disk. In the event of a server failure, the database is still all there.
2. The client library has the resources to restart the daemon if it can’t find the daemon. This means that the daemon going away doesn’t cause any problems.
3. IPC is done through a UNIX-domain socket, so there’s no resources tied up if the daemon aborts.
4. Path names are stored whenever possible. This makes it easier to recover if files change their inode numbers.
5. A large number of sanity checks are performed. For instance, if the database thinks a given file is a plain file, and it has become a directory, the database entry is flushed, because it is necessarily invalid.
6. When sanity checks are performed, it is usually possible to identify both the previous path and current path, and previous inode and current inode, of a mismatched file. This can help narrow down where the error came from.
7. There are a lot of debugging options (although the debugging output is, unfortunately, a bit more verbose than it probably should be).

Because pseudo tracks both paths and dev/inode pairs, it is pretty good at recovering from common errors. (One planned enhancement is to provide better support for updating the database when you know specifically what’s changed, such as remounting an NFS filesystem.)