On 2012-02-04 08:55, Vincent Bernat wrote: > OoO Peu avant le début de l'après-midi du jeudi 02 février 2012, vers > Andreas Beckmann <deb...@abeckmann.de> disait : > >> I'm planning to file bugs against all packages that currently fail the >> piuparts test with a 'deluser/delgroup: command not found' error in >> wheezy and sid. >> Currently 17 binary packages from 15 source packages are affected. > > deluser allows the use of "--system" to avoid to remove a real > user. userdel does not have this kind of switch. Using userdel instead > of deluser is dangerous. I would prefer to leave the user untouched than > removing the wrong user instead. Of course, the postrm script should not > stop because of this (|| true).
I have revised the template to include a link to the discussion about not removing system users on package removal: Hi, during a test with piuparts I noticed your package failed to purge due to a command not found. According to policy 7.2 you cannot rely on the depends being available during purge, only the essential packages are available for sure. The fix should be easy: your package is using adduser or deluser from the adduser package, which is only priority important. Using useradd or userdel from the passwd package (priority required) should fix this problem. There is ongoing discussion how to handle system users on package removal, see http://bugs.debian.org/621833 Consensus seems to be not to remove system users (to avoid reusing UIDs which could grant access to the wrong files) but to "lock" them (where "locking"/"unlocking" is not yet precisely defined). Until that has been decided it should be sufficient to have the postrm script ignore any errors from deluser: deluser ... || true Filing this as important because a.) it's a clear policy violation (to not clean up at purge) b.) having a piuparts clean archive is a release goal since lenny and c.) this package being piuparts buggy blocks packages depending on it from being tested by piuparts (and thus possibly the detection of more severe problems). From the attached log (scroll to the bottom...): cheers, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6afc80.30...@abeckmann.de
