[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <debian@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


Reply to: