Michael Biebl: > Am 30.08.21 um 18:31 schrieb Vincent Lefevre: >> Package: systemd >> Version: 247.9-1 >> Severity: critical >> Justification: breaks unrelated software >> >> systemd provides a dangling symlink: >> >> $ ls -l /lib/systemd/system/portmap.service >> lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36 >> /lib/systemd/system/portmap.service -> rpcbind.service >> $ ls -L /lib/systemd/system/portmap.service >> ls: cannot access '/lib/systemd/system/portmap.service': No such file >> or directory > > This symlink is created via > > dh_link lib/systemd/system/rpcbind.service > lib/systemd/system/portmap.service > > I wonder if debhelper can do something about this or if this is one of > the cases where the package is best updated manually. > > I suspect we have a few packages which create such aliasing symlinks via > *.links files or explicit calls to dh_link > > > Niels, what's your thought on this? > > >> This breaks checkrestart: > > [...] > > Regards, > Michael >
My thought is that this is not something I want in dh_link - dh_link has no business second guessing the link values it gets. Since dh_link runs after dh_installsystemd, then we cannot even rely on dh_installsystemd to perform a fix up either. Which begins to smell like that either people have to update their dh_links calls/configuration OR we roll back the dh_installsystemd change to move to /usr. I am not particular fan of either. :-/ Nevertheless, I am inclined to do a rollback and then punt on the "/ -> /usr" migration track for now. ~Niels
