On 2015-03-06 11:07, Rolf Leggewie wrote: > thank you for the report. I'm a bit puzzled now as to what is the > appropriate way to handle this. I asked in #debian-mentors and even > pabs didn't know a definite answer. I poked around other packages for > guidance and inspiration and I'm still unclear.
Good question ... > 3) handle removal only in postrm, but test for existence of the binary > atftpd does this > purge will succeed, but possibly leaving cruft behind > > None of these seems to be any good, really. So maybe there is a #4? > Using sed or something like that? I would probably settle for #3. If there is no update-inetd, there is also no inetd, so any cruft left in /etc/inetd (if it even still exists) would be harmless until inetd is installed again. And doing a fresh installation of inetd with a preexisting ancient /etc/inetd.conf may be fun on its own. Do not mess with inetd.conf manually to clean up some potential cruft. Andreas PS: please not that the postrm gets called twice, once as "postrm remove" where all dependencies are still available, and once as "postrm purge" where no non-essential packages are guaranteed to be available. And in piuparts we test behavior in that extreme case, which may not be too common in reality. If I'm doing piuparts tests that check for proper cleanup after a package is gone, I usually add some fake-essential packages that are used in postrm purge to perform more cleanup. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
