Hi! On Sun, 2018-08-12 at 14:50:28 +0200, Roland Rosenfeld wrote: > Package: update-inetd > Version: 4.46 > Severity: important
> I had to notice that installing package dictd on a sid chroot fails > since update-inetd was upgraded from 4.45 to 4.46. > (see CI logs of ding which installs dictd as a test dependency: > https://ci.debian.net/packages/d/ding/unstable/amd64/). Sorry about that, I've got now a fix for this locally, and will upload an update-inetd package tomorrow. > I tracked this down a little and in the postinst of dictd I find the > following code: > update-inetd --disable dict > (which is called if dictd should run as daemon instead via inetd). > > On this chroot no /etc/inetd.conf exists. So I expected that > update-inetd --disable dict > should simply terminate with return code 0 (as it does with 4.45), but > the 4.46 version terminates with return code 2, which leads > dictd.postinst to fail. I guess it does make sense to consider disabling and removing services when there's no inetd.conf to be no-ops, as it's equivalent to an already disabled or removed action. > For testing I downgraded to 4.45 and now it works as expected again: > > root@dinghy:/var/lib/dpkg/info# dpkg -i /tmp/update-inetd_4.45_all.deb > dpkg: warning: downgrading update-inetd from 4.46 to 4.45 > (Reading database ... 15458 files and directories currently installed.) > Preparing to unpack /tmp/update-inetd_4.45_all.deb ... > Unpacking update-inetd (4.45) over (4.46) ... > Setting up update-inetd (4.45) ... > root@dinghy:/var/lib/dpkg/info# update-inetd --disable dict > root@dinghy:/var/lib/dpkg/info# echo $? > 0 > > > Since this looks like a bug in update-inetd I report the bug against > update-inetd and not against dictd. Sure. Although dictd and many other package are actually in a way buggy, because they do not follow the stated "contract" of the update-inetd interface, which is that only inet-superserver providing packages should depend on that one, because it's considered an implementation detail of the superserver, and service should instead depend on an inet-superserver virtual + readl package.. But, given that I'd like to soon start switching to declarative inetd support, fixing this right now seems a bit pointless anyway. :) Thanks, Guillem
