Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.bugs.dist    |    Ohh some weird Debian bug report thing    |    28,835 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 27,141 of 28,835    |
|    Santiago Vila to Helmut Grohne    |
|    Bug#1082433: base-files: is /var/lock a     |
|    11 Feb 26 02:20:01    |
      From: sanvila@debian.org              (Adding Chris to Cc as he was involved in the usr-merge change       that happened in base-files 13.3).              On Sat, Sep 21, 2024 at 09:04:02AM +0200, Helmut Grohne wrote:              > On Sat, Sep 21, 2024 at 01:19:39AM +0200, Guillem Jover wrote:       > > $ dpkg-deb -c base-files_13.5_amd64.deb | grep var/lock       > > drwxrwxrwt root/root 0 2024-08-04 23:30 ./var/lock/       > >       > > In this case I think the best option is to simply stop shipping the       > > /var/lock directory.       >       > This hints at another problem. Whilst base-files' data.tar lists       > /var/lock as a directory, its postinst turns it into a symbolic link       > pointing at /run/lock. If dpkg were to verify that /var/lock indeed is a       > directory it would also issue a warning or error. I think this       > inconsistency within base-files should also be solved in addition to the       > one in drbd-utils.              Sorry for the late reply.              I agree that this is an inconsistency and that we should try to fix it,       but I don't really know how much risky the solution will be.              The attached patch seems to work for me, I tested it by doing this:              dpkg -i base-files_14.0_amd64.deb              and nothing bad seems to happen. After the new base-files is installed,       both /var/lock and /var/run are symlinks, while they still belong to       base-files, and the postinst does not do any dirty trick anymore.              I have not tested if debootstrap handles this ok or not.       (can anybody help me to test that?)              And I also don't know if it's ok to do this change in base-files       before we fix drbd-utils, or maybe we should fix drbd-utils first.              If we make /var/lock to be a symlink which belongs to base-files and       drbd-utils is fixed later so that it does not contain /var/lock       anymore, what will happen with /var/lock?              (Maybe the fact that those symlinks are still part of base-files       is what will allow drbd-utils to drop the directory without       creating a mess)              [ Note: I also plan to make those symlinks relative once that Debian        Policy editors allow me to do so, and maybe I will do that in the        same upload, but that's a completely orthogonal thing so I'm        ignoring that for the purposes of discussing this bug ]              Thanks.       commit 840a571d7fe163d3c76f6236563b6f9e8bd7a9cb       Author: Santiago Vila |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca