[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 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: