Comment 13 for bug 862129

I discussed this bug at length with Adam on Friday afternoon. Adam is on vacation now so I'll try and reproduce my memory and conclusions from this conversation.

Some thoughts from that discussion:

1) perl-modules (which provides File::Temp) seems to spend a lot of time unconfigured in the upgrade process. Adam pointed out that this is an anomaly given how much packages depend on Perl in general, and that the problem might be considered to be with the Perl transition and fixing this may be one approach. Take a look at VarLogDistupgradeTermlog.gz in bug 856309 for example - perl and perl-modules are unpacked but not configured in the entire session. I understand that this still complies with policy; the way I see the problem is that perl-modules and update-inetd still need to export some kind of mechanism to make them usable within maintainer scripts for them to be useful.

2) If update-inetd is supposed to be able to be used from within maintainer scripts, what is the correct way of doing so? If it is supposed to be used from a postrm and thus cannot rely on perl-modules to be configured, then is the bug really that update-inetd is depending on things that it cannot?

3) If we could change update-inetd to not depend on Perl modules that may not be configured, then this particular bug wouldn't be an issue any more. It looks like we may only need tempfile anyway, which is in debianutils and Essential. The advantage of File::Temp seems to be portability, which isn't an issue for us as we guarantee tempfile to always be available. update-inetd also appears to need File::Copy so I'll need to check this, but in any case would the approach of removing dependencies by bringing minimal implementations into update-inetd be acceptable?