On Sat, Sep 13, 2014 at 7:12 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Yeah, that's what the 1st response in the bug report basically said: pacman DB location is a cosmetic detail.
No, it is not: /var will be wiped, so having the pacman DB there is not a good idea.
Also, note that systemd features like factory reset and/or atomic updates make no sense in the context of a rolling-release distro like Arch (or any distribution for that matter), so I doubt that they can be a sufficient motivation for this DB move...
I completely disagree: Factory reset is great, especially for a distro involving a lot of manual tweaking like arch:-) With factory reset you always know how to undo your own changes, getting back to the default state. That works for either all changes ever done to the system (factory reset) or selectively by just removing the configuration files you tweaked last. So factory reset is nice, but the image based installation is the best thing since sliced bread. I do that for a couple of month now (using ostree, not the new systemd way). It is a game changer. Basically I create new images of *all* my machines (physical machines, VMs and docker images) each night. That is really easy to do with arch's pacstrap and a bit of configuration that gets applied on top (and moving a couple of files around, e.g. the pacman DB;-). I then store the store the physical machine images in ostree (I am currently changing that to the subvolume approach systemd recently suggested). Now I can test the my new arch snapshot in the new image by either using systemd-nspawn or by starting it in a VM. I can also just reboot into the new image... if it breaks, the old, working image is just another reboot away. Moving the pacman DB is one step to make such a setup a bit more easy to create and It does not effect the traditional use case at all. You can even put the pacman db into e.g. /usr/lib/pacman/db for new installations and fall back to the current location in /var if there is no DB there. Best Regards, Tobias