Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
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 <firstname.lastname@example.org> 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:
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
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...):