Hm. Everyone has raised valid points here, and I understand that in
practice it's difficult to sort this out due to missing history.
I'm satisfied with the wording that Russ proposed to help clarify
things regarding the copyright year, in lieu of a full author list.
(In hindsight it's always nicer
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,
The people participating are:
ron is Ron Lee
pusling is Sune Vuorela
Manoj is Manoj Srivastava
Manoj> config script is called first, before stuff happens, and passed
Manoj> configure. Then the postinst is run, and the config script runs
Manoj> again, but should not ask the quest
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
6 matches
Mail list logo
