tag 240092 wontfix thanks Hi!
On Thu, 2004-03-25 at 19:51:21 +0100, Alberto Marmodoro wrote: > Package: dpkg > Version: 1.10.20 > Severity: wishlist > What about moving, or at least linking, the default location for the > dpkg lockfile from /var/lib/dpkg/lock to /var/lock/ ? On Sun, 2009-08-09 at 09:22:44 +0200, martin f krafft wrote: > What are the plans to fix address this proposal? Debian is very big > on policy and FHS-compliance, and then its most core piece of > software doesn't really fit into the system properly, and in 5+ > years, noone even cared enough to even comment? I've pondered about this bug report for some time now, and I don't really see the point in it. Conformance for conformance sake? What's gained by moving the lock files to /var/lock? I can see the point in unifying location for stuff like log files, caches, backups, binaries, etc, but the disadvantages brought by moving the lock files do not seem worth considering (see down below), regardless of what I take as an incorrect and/or too strict interpretation of the FHS. Let me explain: <http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES> Talks about lock files in general, but immediately clarifies this is about device and other resource files, using the UUCP locking convention, which does not apply here at all, dpkg uses file region locking, which could as well be used directly on the DBs. <http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBLTEDITORGTEDITORBACKUPFILESAN> As an explicit example of the above, you can see that the spec explicitly mentions that editor lock files are quite a different thing to device locks, and as such do not belong under /var/lock. <http://www.pathname.com/fhs/pub/fhs-2.3.html#VARSPOOLLPDLINEPRINTERDAEMONPRINTQU> Here also mentioned explicitly the printer locks. > It seems that dpkg is designed to support non-standard --admindir > settings. It's also quite likely that that feature is in use. It is extensively, yes. > I can thus only think of two ways to really address the issue: > > 1. move all lockfiles to admindir/lock/, which can be a symlink to > /var/lock/dpkg This would need a symlink farm for compatibility, because external software (starting with apt) also make use of the lock to know when the several databases are in use, making that in fact an API. Ideally everything would be using libdpkg to lock the db, but we are not there yet, and then "legacy" applications would need to be supported for a period of time, even after all of them have been hunted down and switched over. Then applications would need to check for both locations as the new one might not yet be present on partial upgrades for example. Also if the applications are going to keep using the location under admindir (as in admindir/lock/), what's the point in moving the actual locks to /var/lock/dpkg? > 2. use a lockdir at /var/lock/dpkg unless --admindir is specified > explicitly, in which case it could heuristically check if > admindir/../../lock/dpkg existed and use that, else fall back to > current method. This seems pretty ugly and unreliable, as it's prone to get the lock file out of sync with the actual db, made worse by the fact that those paths should be changable at configure time. And adding something like --lockdir would not help either. > Thoughts? I'm marking this wontfix for now, but will be closing in a bit if no strong counter arguments are brought forward. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
