[pacman-dev] Lock file location
Just thinking about this while changing some other stuff this morning (permissions checking by libalpm and pacman). Here is the current "default" situation: DB Path: /var/lib/pacman/<dbname> Lock file: /var/run/pacman.lck Remember that the lock file formerly resided in /tmp/, but that is not exactly a FHS-prescribed path. My proposal is this- when we create a lock file, it is for one purpose- to lock the database. Perhaps we should indicate this a bit better, and have one less path that needs to be manually configured, by simply making the lock file a part of the DB and generalizing the lock method to something that could eventually use any backend? In an extreme case, we could lock each individual DB seperately, but for now, a single lock file here: /var/lib/pacman/db.lck would seem to suffice. Is this acceptable to everyone? The benefit it gives us is if this location is writable, the DB is surely writable by the user running pacman, and we can remove the dependence on the pacman user being root. We will still need to do some permission checking on install/pre-install, but I'll think about that later. :) -Dan
Dan McGee wrote:
Just thinking about this while changing some other stuff this morning (permissions checking by libalpm and pacman). Here is the current "default" situation: DB Path: /var/lib/pacman/<dbname> Lock file: /var/run/pacman.lck
Remember that the lock file formerly resided in /tmp/, but that is not exactly a FHS-prescribed path. My proposal is this- when we create a lock file, it is for one purpose- to lock the database. Perhaps we should indicate this a bit better, and have one less path that needs to be manually configured, by simply making the lock file a part of the DB and generalizing the lock method to something that could eventually use any backend? In an extreme case, we could lock each individual DB seperately, but for now, a single lock file here: /var/lib/pacman/db.lck would seem to suffice. Is this acceptable to everyone? The benefit it gives us is if this location is writable, the DB is surely writable by the user running pacman, and we can remove the dependence on the pacman user being root. We will still need to do some permission checking on install/pre-install, but I'll think about that later. :)
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Sounds like a good idea. How pacman locks the database is completely dependent on what backend is being used to it belongs with the rest of the backend code. Andrew
On Mon, 11 Jun 2007 10:40:15 -0400, Dan McGee wrote
Is this acceptable to everyone? The benefit it gives us is if this location is writable, the DB is surely writable by the user running pacman, and we can remove the dependence on the pacman user being root.
It sounds reasonable to me, but in the 10 minutes of thought I've given to it just now, I can't visualize a case where we wouldn't need to be root when the database needs to be locked anyway. Locked DB generally means writing to DB, ie adding/removing pkgs, which requires root anyways. Am I wrong? -- Travis
On 6/11/07, Travis Willard <travis@archlinux.org> wrote:
On Mon, 11 Jun 2007 10:40:15 -0400, Dan McGee wrote
Is this acceptable to everyone? The benefit it gives us is if this location is writable, the DB is surely writable by the user running pacman, and we can remove the dependence on the pacman user being root.
It sounds reasonable to me, but in the 10 minutes of thought I've given to it just now, I can't visualize a case where we wouldn't need to be root when the database needs to be locked anyway. Locked DB generally means writing to DB, ie adding/removing pkgs, which requires root anyways. Am I wrong?
I'm thinking outside of the box here. What if I, as a normal user, want to install packages in a chroot environment? It would use a separate pacman DB and separate root directory. In addition, the biggest advantage is taking pacman and using it to install packages elsewhere, such as on Dreamhost in my home directory. -Dan
On Mon, Jun 11, 2007 at 10:40:15AM -0400, Dan McGee wrote:
Just thinking about this while changing some other stuff this morning (permissions checking by libalpm and pacman). Here is the current "default" situation: DB Path: /var/lib/pacman/<dbname> Lock file: /var/run/pacman.lck
Remember that the lock file formerly resided in /tmp/, but that is not exactly a FHS-prescribed path. My proposal is this- when we create a lock file, it is for one purpose- to lock the database. Perhaps we should indicate this a bit better, and have one less path that needs to be manually configured, by simply making the lock file a part of the DB and generalizing the lock method to something that could eventually use any backend? In an extreme case, we could lock each individual DB seperately, but for now, a single lock file here: /var/lib/pacman/db.lck would seem to suffice. Is this acceptable to everyone? The benefit it gives us is if this location is writable, the DB is surely writable by the user running pacman, and we can remove the dependence on the pacman user being root. We will still need to do some permission checking on install/pre-install, but I'll think about that later. :)
-Dan
Sounds fine to me, just as long as there's always an easy way to remove the lock. You know, when pacman crashes... ;) If the lock were moved inside a sqlite db (or something) there'd have to be a script to remove the lock. Heck, we could generalize that too. Jason
participants (4)
-
Andrew Fyfe
-
Dan McGee
-
Jason Chu
-
Travis Willard