Hi,
On Thu, 2007-01-11 at 13:40:21 +1100, Brian May wrote:
> We really need a constant way of dealing with this in package updates.
>
> It seems to boil down to:
>
> * should packages disable inetd config entries on removal and in
> preparation for upgrade, and then reenable the entries after upgrade
> is complete?
I agree with Andreas, if you don't have to change the current entry I
don't see the point in enabling and disabling it. And I'm removing the
entries on package removal.
> * what about entries that should be disabled by default? That is the
> maintainer has decided the majority of users will not need it?
I'm installing entries disabled by default, and although my current
approach feels a bit dirty, seems to work. For example the snippets
for inetutils-telnetd:
,--- postinst ----
if [ "$1" = "configure" ]; then
if [ -x /usr/sbin/update-inetd ]; then
update-inetd --group STANDARD \
--add "#<off>#
telnet\tstream\ttcp\tnowait\troot\t/usr/sbin/telnetd\ttelnetd"
fi
fi
`---- postinst ----
,--- postrm ----
if [ "$1" = "remove" ]; then
if [ -x /usr/sbin/update-inetd ]; then
update-inetd --group STANDARD --remove '^(#<off># |)telnet'
fi
fi
`--- postrm ----
Arguably this cases should be handled by update-inetd, but we know it
needs some fixing.
Hmm now looking at this, I should be using which instead of the full
path for update-inetd...
regards,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
