>>
>> The real answer depends on if the user is going to lose functionality (or
>> gain
>> unwanted functionality). If this is simply "I have renamed these and put
>> them
>> in /etc/foo" you should be able to get away with debconf. But if there is a
>> possibilty the user (and this should be a fair number of users, not like 1
>> or
>> 2) have seriously mod'ed the file you have a bigger problem on your hands
>> and
>> should consider supporting both the old and the new files.
>
> In principle they have moved to another location,
> /etc/network/if-{up,down}.d,
> and at the same I have greatly changed them. What happens if they are not
> removed is that both of them will be executed. They both start a process
> in background (fetch and/or send mail). Whatever will be executed first
> will block (by a lock file) the second, because it is likely that the
> time span between them is short. The old scripts also depend on a conf file
> which is obsolete as well (it is still there, because it is a conffile, but
> not supported by debconf).
>
> My worries are that I get lots of bug reports because the package does not
> behave as expected by the users.
>
So why not chmod -x them in your postinst and pop up a debconf note that
explains the new situation. The scripts are not removed, they are simply
disabled. Also document this in your changelog and in README.Debian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
