Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Dec 2005 14:27:04 +0100, Lionel Elie Mamane <[EMAIL PROTECTED]>
> said:
>
>> On Sun, Dec 25, 2005 at 09:23:23PM -0600, Manoj Srivastava wrote:
>>> On Sun, 25 Dec 2005 19:59:07 -0200, Rogério Brito
>>> <[EMAIL PROTECTED]> said:
>>>> On Dec 25 2005, Lionel Elie Mamane wrote:
>
>>>>> Ah yeah, this seems to contain the information. Thanks a lot. Is
>>>>> there a good reason it is not in the policy?
>
>>> Policy is not the place to put documentation that belongs to
>>> packages?
>
>> How can specifying when and with what arguments a maintainer script
>> gets run belong to a package? If it does, why isn't
>> {pre,post}{rm,inst} documentation in dpkg's documentation rather
>> than in the policy?
>
[...]
> The idea is for policy not to be an obstacle in development of
> the debconf/packaging system, while specifying enough of an interface
> that developers can rely on some things being constant from upload to
> upload.
And I thought I could rely upon dpkg from the next upload to call the
configure script with the same arguments as it did before, just as I can
rely on the same for preinst, postinst etc.
We're not talking about the debconf interface at all here, AFAIS. We're
talking about the interface that dpkg provides to packages for there
debconf questions, i.e. the way the configure script is called, and
when.
Do you think it would be an obstacle for development if that were
documented in the Policy, just as the same is documented for the
"classical" maintainer scripts? Why isn't it an obstacle for those
other scripts?
Do you imply we should not rely on the time point when dpkg calls the
configure script, or on the arguments it passes to it? Why?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
