Joey Hess <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>> Because it isn't true that the previous version didn't use debconf. It
>> just asked the questions totally differently and took an approach that I
>> now would call flawed. But still it gave the users the impression that
>> their ls-R
Frank Küster wrote:
> Because it isn't true that the previous version didn't use debconf. It
> just asked the questions totally differently and took an approach that I
> now would call flawed. But still it gave the users the impression that
> their ls-R files' permissions are managed by debconf,
Hi Joey,
thanks for being patient with me. I promise that I'll write this up
(for debconf-devel(7) or the developer's reference or whatever you
suggest) once we've sorted this out.
Joey Hess <[EMAIL PROTECTED]> wrote:
>> Does that mean I must use some hackish handmade flags that are reset
>> o
Frank Küster wrote:
> Sorry for still being dumb. When it's reconfigure, I have just learned
> that the config script is run only once, so I need not handle this case
> specially. But when its an upgrade, it is run twice, and I need to
> discriminate between the first pass (check existing permiss
Joey Hess <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>> I found no way to cleanly solve the problem of
>>
>> - writing the current state into the debconf database, so that
>> noninteractive installs don't change anything
>>
>> - actually reflect changed answers in the system.
>
> The co
Frank Küster wrote:
> I found no way to cleanly solve the problem of
>
> - writing the current state into the debconf database, so that
> noninteractive installs don't change anything
>
> - actually reflect changed answers in the system.
The config script is passed parameters that you can use
Joey Hess <[EMAIL PROTECTED]> wrote:
> dpkg-reconfigure runs the config script exactly once, so the config file
> is read once, its values are used for defaults to the questions to allow
> reconfiguration, and are saved to the config file by the postinst.
Yes, I was wrong about this - it's only r
Frank Küster wrote:
> However, in case apt-utils is installed, this script will be run twice:
> Once by dpkg-preconfigure, i.e. in the preinst stage, and once by
> confmodule when the postinst script sources confmodule. As far as I can
> see, this will have a confusing effect. Assume the configfi
Hi,
I posted this question yesterday on -mentors, but since nobody answered,
it seems it isn't as trivial as I had hoped.
I have either some fundamental misunderstanding of how debconf or
maintainer scripts work, or there is an error in the descriptioin of how
debconf-using scripts should handle
Ludovic Drolez <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>> Please try to debug by putting a "set -x" into
>> /var/lib/dpkg/info/backuppc.postrm (or prerm, whatever it is). If it
>> really hangs at db_purge, it may be a bug in debconf. You should know
>> that.
>
> Yes, I've alread tried th
Frank Küster wrote:
> Ludovic Drolez <[EMAIL PROTECTED]> schrieb:
>
>
>>The postinst script seems to be stuck in db_purge, a line which was
>>added automatically:
>
>
> The postinst script is not executed upon purging a package. Probably you
> mean the postrm script?
Yes.
>
>>...
>># Autom
11 matches
Mail list logo
