The fetchmail source package used to generate a SSL version of fetchmail
and a non-SSL version, along with a -common package used by both. The
-common package took care of creating and removing the user needed by
either package.

The fetchmail source package now only generates one package (with SSL
support), and it handles creating and removing the user it needs.

Upon upgrading from multi-package version of fetchmail to the
latest version, fetchmail-common is removed from the system, and removes
the fetchmail user as well. This leaves the newest fetchmail package
without a user to run as.

What is the best way to fix this? This only way I can think of (as was
suggested in #268228) is to check in the init script whether the user
exists, and, if not, to create it.

Is this a good solution to the problem? If not, what should I do?

--
gram


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

hi graham,

On Sun, Aug 29, 2004 at 09:12:59PM -0500, Graham Wilson wrote:
> Upon upgrading from multi-package version of fetchmail to the
> latest version, fetchmail-common is removed from the system, and removes
> the fetchmail user as well. This leaves the newest fetchmail package
> without a user to run as.
> 
> What is the best way to fix this? This only way I can think of (as was
> suggested in #268228) is to check in the init script whether the user
> exists, and, if not, to create it.
> 
> Is this a good solution to the problem? If not, what should I do?

how about putting code in your maintainer scripts that determine if it's
upgrading from the multi-package version, and if so, re-creates the user?  


sean

[ Post a follow-up to this message ]

On Sun, Aug 29, 2004 at 09:12:59PM -0500, Graham Wilson wrote:
> Upon upgrading from multi-package version of fetchmail to the
> latest version, fetchmail-common is removed from the system, and removes
> the fetchmail user as well. This leaves the newest fetchmail package
> without a user to run as.

You should simply not remove users. You cannot possibly know whether
your package, or the system administrator has made any files owned by
that user. I could imagine a system administrator making a directory for
fetchmail, with fetchmail owned files in it. By removing the user, you
'orphan' those files, they don't have a symbolic user anymore, and
worse, when the next system user is added to the system, that user will
suddenly own those files that were not meant for him. You cannot just
remove all those files, or chown them, if only because at upgrade time
for example the NFS partition with those files is possibly unmounted.

I'm not really backed up by policy on this one, I think this should be
in there, for reasons I stated above.

> What is the best way to fix this? This only way I can think of (as was
> suggested in #268228) is to check in the init script whether the user
> exists, and, if not, to create it.

This should probably be done anyway, too.

--Jeroen

--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

* Graham Wilson [Sun, 29 Aug 2004 21:12:59 -0500]:

> Upon upgrading from multi-package version of fetchmail to the
> latest version, fetchmail-common is removed from the system, and removes
> the fetchmail user as well.

[relevant information: fetchmail provides, replaces and conflicts
fetchmail-common.]

most likely, the 'fetchmail' user won't get removed; only if the user
passes --purge to apt-get or whatever. which you mostly want to
happen, since the 'fetchmail' user will be created again in the
fetchmail.postinst script in the same apt-get run.

so the real problem is, as in the bug report, when the user purges the
-common package (which will be in state 'removed') *after* the
transition split packages ==> single packages has happened.

> What is the best way to fix this? This only way I can think of (as was
> suggested in #268228) is to check in the init script whether the user
> exists, and, if not, to create it.

I can think of three other alternatives:

(a) re-introduce the fetchmail-common package as a dummy package,
and make the fetchmail package (versioned) depend on it.

(b) re-introduce the fetchmail-common package, make the fetchmail
package conflict with fetchmail-common << 6.2.5 or so and put in the
f-common description somethink like:  "Dummy package to help
transition from woody. You may safely purge this package once it has
been installed."

(c) <evil mode> in the fetchmail.postinst script, put some code
equivalent to "echo >/var/lib/dpkg/info/fetchmail-common.postinst"
(if the file exists), neutralizing the parts of it you never want
executed anymore. (does policy forbid that?)

all have their pros and cons, and perhaps the original init.d one,
being uglier, is more robust that these ones. but it *really* does not
address the problem of having not-to-be-executed code in
fetchmail-common.postinst for an unknown amount of time (when would
you remove the check from the script?) I wrote my alternatives with
that issue in mind (the -common package could go right after sarge
releases, and so the hackery in f.postinst).

cheers,

--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621

In my opinion, the most fruitful and natural play of the mind is in
conversation. I find it sweeter than any other action in life; and if I
were forced to choose, I think I would rather lose my sight than my
hearing and voice.
-- Michel de Montaigne


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

Jeroen van Wolffelaar wrote:
> You should simply not remove users.

Right.

> I'm not really backed up by policy on this one

This should be settled by policy.
--
Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]