Bug#1039979: /var/run and /var/lock should not be absolute symlinks

Bastien Roucaries <[email protected]> Fri, 20 Feb 2026 14:15:58 +0100

Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<2785725.KRxA6XjA2N__10014.3931269244$1771593453$gmane$org@debian-ei>

Le vendredi 20 février 2026, 12:22:38 heure normale d’Europe centrale Santiago Vila a écrit :
> On Fri, Feb 20, 2026 at 11:03:38AM +0000, Sean Whitton wrote:
> > Russ Allbery [08/Feb 11:36am -08] wrote:
> > > This feels like the sort of change that maybe we should discuss on
> > > debian-devel if it feels like we have consensus here on the Policy list.
> > 
> > I think if the maintainers of the packages in which the change would be
> > effected are on board, we don't need to do that.
> 
> For /var/run and /var/lock, I believe systemd already has those symlinks
> as relative.
> 
> I also think it would be better to have them relative, and the main
> reason I reassigned this from base-files to debian-policy is that I
> wanted to avoid anybody telling me that I was violating policy by
> doing the change on my own...
> 
> While we are at it, I wonder if we could actually deprecate those
> locations for forky, and what would be the steps for doing so.
> 
> There is a small anomaly in the way base-files handles /var/lock
> (see #1082498) and Helmut tells me that fixing the anomaly the right
> way might require additional code similar to the one introduced in
> base-files 13.3 for the usr-merge.

I think for /var/lock we could use dpkg-maintscript-helper dirtosymlink

The only condition is that the link should be relative to ./run/lock instead of /run/lock

rouca
> 
> I don't have any hurry in fixing the anomaly, but maybe if we
> deprecate /var/lock first, fixing the anomaly would be easier
> (i.e. not requiring use-merge-grade machinery).
> 
> Thanks.
>

signature.asc (application/pgp-signature, 833 B)