On Thu, Jul 02, 2009 at 11:20:19AM -0700, Russ Allbery wrote:
> > The question is, why should we change something so deeply
> > deployed as package postinst API without compelling reasons that the
> > postinst should treat an upgrade differently from a reconfigure,
> > especially since t
sean finney writes:
> On Thu, Jul 02, 2009 at 09:44:50AM -0500, Manoj Srivastava wrote:
>> The question is, why should we change something so deeply
>> deployed as package postinst API without compelling reasons that the
>> postinst should treat an upgrade differently from a reconfigure
On Thu, Jul 02, 2009 at 09:44:50AM -0500, Manoj Srivastava wrote:
> The question is, why should we change something so deeply
> deployed as package postinst API without compelling reasons that the
> postinst should treat an upgrade differently from a reconfigure,
> especially since the u
Manoj Srivastava writes:
> The question is, why should we change something so deeply
> deployed as package postinst API without compelling reasons that the
> postinst should treat an upgrade differently from a reconfigure,
> especially since the user interaction part is already correct
Hi,
A postinst may be called with the following arguments:
* `configure'
There are three sub-cases:
1) there is no second argument -- ancient dpkg, not
relevant these days
2) the second argument is "" or "", fresh
install.
3) The second argument is t
5 matches
Mail list logo
