Re: diskles-image-*
Brian May <bam@debian.org> 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
> compatable?
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
base-config thingie.
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/>
Reply to: