Allan McRae wrote:
This would also give another use for "pacman -D" - an option could be added to recreate the local db tarball - in case it became corrupt or the files were manually edited.
That would be an essential function as manual edits are quite common.
The thing you are missing is EVERYTHING in pacman apart from the local db is in tar format. The packages are tarballs, the sync dbs are tarballs. We use a very good library for reading from tarballs without extracting them.
"We have a really shiny hammer and and a lot of nails, so we may as well just use our shiny hammer on everything." It makes sense that packages are tar archives. A package is a fixed set of files arranged in a hierarchy. That's what tar was meant to store. Databases on the other hand are different. You can argue it any which way you want, but it's obvious that the multiple files/tarred archive approach was a lazy shortcut to avoid a proper solution that would have required time to implement, test and debug. At first Judd or whoever presumably just wanted to get it working, and subsequent improvements were made on what was already there. Now it's grandfathered in with all the emotional attachment and a proud member of the "good enough" club, but that does not mean that it's optimal. SQLite makes sense for both sync and local databases. I expect it would be faster and more versatile. The data would be stored in a common data format and not require custom files and parsers. It would facilitate the creation of third-party tools. Is this a big deal? No. As stated, the current solution is already "good enough". Further improvements will be welcomed, but there must come a point where you ask yourself if complicating an existing suboptimal solution to shave off a few seconds is really better than implementing a proper solution to the problem. Eventually you will want a proper solution, and then the current effort will be at least partially wasted. All that aside, +1 for tarring the local db to improve speed, as long as the local files remain easily accessible for manual editing. Regards, Xyne