Re: unused parameters passed to maintainer scripts
On Mon, Oct 26 2009, Eugene V. Lyubimkin wrote:
> Manoj Srivastava wrote:
>>> But some of people-written snippets have, often doing it wrong.
>> Can you point to some examples? Have you filed bug reports?
> I filed #552389, a good example (IMO) of confusing due to complexity. There
> are plenty of packages that do checks of parameters that are passed to script
> and then doing completely nothing with them. Some packages tend to think that
> 'disappear' is equal to 'remove', others think that it's equal to 'purge', so
> either first or second set is doing wrong.
>>>> I also think that there might be packages that take specific
>>>> action on those cases in the future; since in all cases packages are
>>>> being removed or disappearing. Having information that distinguishes
>>>> which part of the state transition is in effect is information may
>>>> be useful, and I see little benefit in removing it.
>>> Can you elaborate on this? Not for convincing me, I'm just curious how
>>> the package can take different actions on removal depending on what
>>> package is the case of removal.
>> What do you mean, how? Are you asking me a basic scripting
>> question? If not, I am failing to understand what you are asking.
> Of course, not. I questioned how this info can be useful, not how to
> write a code for it.
How can it be useful? Well, If I had needed to take different
action (conflicting package installed as opposed to user removal), the
information would have been critical.
If you meant *why* such distinctions are useful, then the answer
is probably that they have not been, so far. But perhaps some packages
want to handle removal differently from the package being fully
>> In any case, look at /var/lib/dpkg/info/ucf.postinst
>> It gives examples of where things can be put in, were you
>> inclined to do different things based on how the script is called.
> It gives only a code template to do different things, but actually
> does nothing.
Right. It has not had to. Yet.
Anyway. I do not have much more to add on this subject, so this
is my last post on it.
A feature is nothing more than a bug with seniority. Unknown source
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C