> Here's an idea for eliminating the race. Ship /sbin/resolvconf without > x permission and have the postinst set the x permission only once > resolvconf is ready for use. (Dnsmasq and other clients generally test > for executable /sbin/resolvconf before calling it.)
The wishlist item in 213591 (using locks) may also be an alternative. But neither locks, nor a +x check is likely practical for all clients, so it is likely to fail as a full fix for some odd cases. Eg: it currently doesn't get around the problem case of if dnsmasq is installed first, and then later (before a reboot) resolvconf is installed next. Should resolvconf really worry about these? If it should, then why not just restart dnsmasq after resolvconf is installed? (I am not yet familiar enough with debian packaging to know if a postinst script dependency check could (or should) do that). Maybe just have a warning that services like dnsmasq that rely on resolvconf may need a restart. (I seem to remember similar warnings for other packages that involved a restart for services, so it may be a debian best practice). It would certainly keep things simple, which is good. regards PJ Addendum: snippet from #debian-devel where I discussed above: <peej> package A installs stuff which requires package B to restart. Is that a job for postinst scripts? <Yoe> peej: I'd say that's a job for a trigger by package B <peej> I am unfamiliar with debian packaging. Can you explain what you mean by trigger? <jcristau> peej: /usr/share/doc/dpkg/triggers.txt.gz <peej> cool. <cortana> or not even triggers. if package b has a daemon that needs to reload, it should just watch the directory containing the files and reload when new ones appear <Yoe> cortana: yes, but then not all daemons do that <cortana> yeah. if the maintainer patches the daemon then other distros can benefit too :) <Yoe> and a trigger may be easier to implement <ron> and you get triple NIH points for a debian specific solution <peej> actually, it concerns http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563386, where the suggested +x solution doesn't solve the edge case of dnsmasq installed first, then, before a reboot is done, resolvconf is installed next. <peej> (package A is therefore resolvconf here, and B dnsmasq that needs the restart) <ron> doesn't resolvconf let you install hooks to do that? <peej> ron, do you mean hooks to specify a restart for all possible services that depend on resolvconf ? <ron> the +x "solution" would seem to violate all manner of good taste conventions <ron> well I see /etc/resolvconf/update-libc.d with some scripts in it .. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
