Author: Norman White Date: To: dyne3 Subject: [dyne:3] debian's boot scripts?
Pandora's box:
Originally, since I didn't have any archives to reference on dyne3's
development -- I assumed that a conserved upgrade would be preferred
among developers. I thought that I should n't do anything that might
create a Pandora's box for the rest of Dyne3's development.
What I thought was that I would use debootscript's output (the Debian
system) without the kernel or ramdisk's in a module, (and deleting all
of /dev's contents) thereby isolating it from interference with a
Dyne3 conservative upgrade.
I figured that I would have Synaptic in its native environment since
it's a frontend to aptitude (debian's stuff) and create a
chroot-environment to use it; a user would then have to use a nest to
retain all of the packages-- the usual thing that the nest does.
The module was supposed to be used just to get multiple 'preset
'packages into one place without modifying or interfering with
Dyne:bolic; the appropriate directories would be bound to the
appropriate directories in the SynapticChroot environment so that the
applications could have access the the appropriate data.
The usual DyneModule would then be used in those cases where one would
want to make available a customized application or
optimized/compatibility hack.
I was thinking that perhaps new nest developments might have been an
upgrade focus for Dyne3.
I think that Dyne 2.5.2 works great. But then, I'm not able to know
what issues may exist.