[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unused parameters passed to maintainer scripts



On Mon, Oct 26 2009, Eugene V. Lyubimkin wrote:

> Manoj Srivastava wrote:
>>         Simplicity of the policy?Is it really that onerous Most people
>>  just let the helper packages create the maintainer scripts, of just
>>  program b example.
> Yes, simplicity of the policy.
>
> From what I saw, no one helper package in sid have some business with
> 'in-favour', 'removing', 'disappear'.

        Because there might not (yet) have been any demand? But that doe
 s not preclude a future implementation from creating one. This by
 itself is not a good enough reason to change dpkg and policy, and
 constrain future maintainer script capabilities.

> But some of people-written snippets have, often doing it wrong.

        Can you point to some examples? Have you filed bug reports?


>>         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. If
 so, does this not belong in debian-mentors or
 comp.,unix.shall.beginner? 

        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.

>>>> The maintainer scripts have to be
>>>> called anyway for those cases, and the fact that no one uses them now or
>>>> in Debian, does not mean there's no use for this information in the
>>>> future or in other places.
>>[...]
>> 
>>         A failure of imagination on our art should not be used to block
>>  this functionality for cases where it might be needed.

> With that kind of arguments, the standards cannot ever rid of unused bits.

        There is a difference between unused and useless.

> I am giving up on this proposal as I see no positive feedback.

        Thanks.

        manoj

-- 
"The first step to getting the things you want out of life is this:
Decide what you want." -Ben Stein
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: