[Dsc-maintainers] Bug#668740: system user setup in /home cannot be ignored

[Neil Williams]

> On Sat, Apr 14, 2012 at 10:03:22AM +0200, Andreas Beckmann wrote:
> > 0m26.0s ERROR: FAIL: Package purging left files on system:
> >   /home/Debian-dsc-statistics	 not owned
> 
> This is very obviously the home directory of the user.

The Debian-dsc-statistics system user, not the user installing (or
configuring) the package. Therefore, as a system user (with the
--system option), the package needs to be patched to put and look
for files for that user in a system user location: /var/lib/
usually. /home is off-limits. That isn't a matter of preference or
convenience, it's a matter of Policy and the package *must* comply or I
*will* file for removal.

#!/bin/bash -e
# postinst

USERNAME="Debian-dsc-statistics"

[ -n "$DSCDEBUG" ] && set -x

# Add user
if [ "$1" = "configure" ]; then
    echo >&2 'Adding system user'
    adduser --system --group --home /home/$USERNAME \
            --disabled-password --force-badname --shell /bin/bash
$USERNAME fi

#DEBHELPER#

--force-badname is bad enough but I don't see why the *system* user
created by this package has any need to create a home user when that
can and should be done just as well in /var/lib/ and then using a path
to any calls to programs which want stuff you put into the directory.

Also, why does the *system* user need a login shell? Are the remote
boxes expected to login to the admin box or copy files backwards?
Usually, that would be better by copying a script to the remote box
which puts output in a known (temporary/managed) location and then
initiating the copy from the admin box rather than having to setup the
remote box to need a login on the admin box. Either way, the name of
that directory does not affect the copy process as the programs
concerned can all be given a specific path to use. 

There must not be changes related to this login behaviour in the fix
for this bug if you want this package in wheezy, it was just something
which occurred to me when I reviewed your package against others I've
written for personal / work support packages. 

(As personal / work support packages, they don't need to comply with
Debian Policy and will never be uploaded to Debian, so I can do stuff
like this because the target system is an embedded device where there
are no user login mechanisms, the entire machine operates via daemons.
Nevertheless, raw experience has taught that the remote box really
should not be logging into the admin box - it all needs to be
controlled from one end or a host of nasty bugs will result. Been
there, done that.)

admin $ sudo apt-get install dsc-statistics-...
(configuration somehow....)
admin calls the scripts which need the user, somehow....

admin: scp report.sh remote:/tmp/
admin: ssh remote:/tmp/report.sh
(report.sh creates output with a known filename, possibly based on the
hostname of the remote box - this is a synchronous, blocking call, so
when it terminates, we either have errors or output in the expected
file.) 
admin: scp remote:/tmp/$(output).dat .

No need for remote: to be able to login to admin:

Whatever, that's a side-issue which would have to be fixed after Wheezy
- maybe via an upload to experimental if the package is not removed in
the meantime. It is not part of this bug and any patch / diff for this
bug should not address it.

> please send a tested and documented patch

That's not a requirement that any maintainer can make on anyone
submitting or commenting on a valid bug. You can request patches but
the bug still has to be fixed and a month has now passed without any
obvious action by the maintainer. It is up to the maintainer to do the
work on the package. If you don't want to make the package comply with
Debian Policy, I offer some possible actions:

0: Ignore this bug and my comments, I'll file a removal bug in ~2
weeks. (That will be to remove from unstable and testing.)

1: Reply to this bug without dismissing it and accepting that it is up
to the maintainer to fix it but don't fix it before, let's say, the
Alcester BSP in October 2012 [0] - I'll file the removal bug at the
BSP or earlier if the release happens before then.

3: Orphan the package yourself, I'll file for removal as RoQA.

4: Remove the package from testing (or from unstable & testing)
yourself.

You can, of course, just reply to this bug in a helpful manner with your
own tested and documented patch and/or simply make the upload which
drops any use of /home to fix this bug (with no changes other than the
fixes for this bug). Then file an unblock request bug with
release.debian.org with the complete debdiff from current testing to
the new package and work with the release team to answer their
questions and agree on getting an unblock implemented.

I've no direct interest in this package myself, I just want to see the
release go smoothly because that will make my life easier at work. If
that means the release does not include dsc-statistics then I truly
do not care, sorry. I do care about maintainers giving the impression
that RC bugs do not matter or that RC bugs can be deemed wontfix without
consideration for the wider release. Consider this as a reminder from
one of your peers that RC bugs have consequences and the *only* thing
that happens if a maintainer ignores them is that the package *will* be
removed from Debian. I intend to implement those consequences if the
bug is not closed appropriately in testing.

Thanks for putting your package on my removal radar. I won't be
commenting on this bug again unless via a removal. (Don't be tempted to
go off-bug either please, that only makes me more likely to seek
removal.)

[0] - http://wiki.debian.org/BSP/2012/10/gb/Alcester

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/dsc-maintainers/attachments/20120819/4fe6deb5/attachment.pgp>