Brian May <email@example.com> writes:
> (Does dpkg-reconfigure re-invoke the preinst and/or postinst scripts?)
No -- rather, the postinst scripts etc run the debconf scripts. The
reconfigure action just reruns the debconf scripts, not postinst
entirely, but I may be wrong.
> I made a fully debconf version of my diskless-image-* packages, when I
> suddenly realized, this will only work if the base*.tgz file contains
> some sort of debconf support. What should I do? Try and manually
> install debconf (this is inconvenient to the user), or does the
> base*.tgz file already have some support for debconf?
base2_2.tgz contains debconf-tiny. See if your script runs under
debconf-tiny. Unless you're doing something tricky, it should.
> What is the difference between debconf and debconf-tiny? Are there any
> things I should watch out for so my packages are debconf-tiny
I am not sure.
> Adam> Ideally, base packages themselves should all support
> Adam> debconf. However, that is not yet so. I am conflicted
> Adam> whether we should try to take at least the postinstallation
> Adam> tasks and debconf-tiny'ify them, and try to either:
> Adam> (a) get the upstream base pkg maintainers to add the
> Adam> scripts (probably not possible)
> I think this sounds the ideal solution. When you say "probably not
> possible", do you mean for technical reasons, or practical reasons (ie
> updating every base package).
Practical reasons alone.
> Adam> (b) make a new little package, base-config which has all
> Adam> this stuff, then you cuold do 'dpkg-reconfigure base-config'
> Adam> or some such
> I think this is the next best thing to (a).
Yes -- it would be cool. We could build it out of boot-floppies.
Now, when root logs in, a number of scripts from roots ~/.profile (I
think!) run -- these should be replaced by an invokation of this new
Just for practical reasons, it would be best if this new pkg or script
or whatever were to be maintained for now out of the boot-floppies CVS
area, since they are so tightly coupled and this allows the fastest
sync and turnaround.
> Adam> (c) just have the scripts be part of the boot-floppies
> Adam> themselves
> I don't think I see any value in this approach, but it would work...
Well, see above.
> >> It has been a while since I looked at this configuration stuff.
> >> Wondering aloud: Are there any parts that are not appropriate
> >> for NFS-Root systems? Probably the network configuration is
> >> redundant (the NFS-Root kernel automatically detects this at
> >> startup).
> Adam> Shaleh and Marcel are working on bootp/dhcp for this, which
> Adam> is more appropriate.
> The difference with diskless boot, is that the network is already fully
> configured by the kernel before any user space process (including
> /sbin/init) starts to execute.
> However, the current kernel versions fail to configure 127.0.0.1
Is this a kernel-image-2.2.13 bug? A boot-flopppies bug?
> >> The loopback (ie localhost) device must be configured though.
> Adam> Ah yes, I think that is done, but only if there is no other
> Adam> network....
> Sure? I think 127.0.0.1 must always be manually configured, even when
> there is another network connection. Otherwise programs that try to
> contact localhost will fail.
I'm not sure -- would you be willing to grub around in the
boot-floppies CVS area? You can have full read/write acces...
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>