Re: packages (was Re: [woody,debinst] `parted' and non-DOS compatible partitioning schemes)
Bruce Sass wrote:
> > > onto an existing Debian system. The boot-floppies .deb is not useful to
> > > the average user, but it can still be installed; debinst .debs would be
> > > installed for the same reasons that someone would want to install the
> > > boot-floppies .deb.
> >
> > Ok, but we'd have to make sure they don't get in the way of the real
> > system, then.
>
> Or are fully integrated into the real system.
Take busybox.deb. You do _not_ want to install that onto a real system.
Ok, maybe some packages will fall out of this that do make sense to be
installed onto a real system, but I don't think that should be a primary
goal, or even much of a consideration, if doing it makes our job a lot
harder or results in bloating the installer.
> ditto for system configuration.
Since my proposal calls for all system configuration aside from
partitioning and sometimes network(/modem) setup to be done inside a real
debian system, this is basically a non-issue.
> > Hm, that's a good idea. Presumes that modules are configured in their
> > preinst or earlier, though.
> Thanks. Pre-depends stuff, eh.
Ugh, I guess it does imply pre-depends. Or does it.. see below.
> Here is a potential problem: The package managers will be able to
> handle pre-depends at some point[1], but will the algorithm result in an
> installation sequence that is correct for installing hardware and
> setting configuration parameters.
I don't think we can count on apt or dpkg supporting predepends. For one
thing, I really doubt we'd be using them in the installer. Just too big.
> I can think of a few solutions:
> Let the installer handle what dpkg+ would
> - breaks modularity because the installer would need to know the
> relative priorities of the modules
Not really. The installer just needs to know that module c (the
formatter) depends on module b (the partitioner), and both depend on
module a (hard disk support). What we can do is break installation and
configuration up into separate steps.
So install a, b, and c. Then configure a, then b, then c.
In fact, this is very like how dpkg handles installing multiple
packages in one run, where by installing I mean putting them on disk,
then configuring them a bit later by running the postinst scripts. The
actual install order doesn't matter, the configuration order does.
--
see shy jo
Reply to: