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

[Fwd: Debian's new installer]

The following is a bit of a description about how Conectiva's installer
--- Begin Message ---
>> >You have probably picked up from the list that cdebconf and udeb
>> >packages are basically the heart of the new debian installer. cdebconf
>> >provides the user interface and installer modules are handled like
>> >regular packages that are fetchable on demand.
>> >
>> >The installer could be almost considered a mini-distribution.
>> >
>> I didn't dive into details on how your installer works (or is going to), but I
>> can have an idea based on s draft I read and what you told me now.
>> Our installer works in a different way: modules are .so libraries. When it
>> detects the presence of 2 or more modules of the same kind, it asks you which
>> one you'd like to use (of course, you can force one in the mi.conf file or add a
>> "detection" routine that chooses one for you according to the context).
>> As I can see, your installer is highly based on separate tools, while ours are
>> completely integrate, although it may not be (we don't use RPM, but librpm
>> instead. And we're planning to write a pm_apt module, that will be a wrapper to
>> apt-get, and this one will be able to handle both .rpm and .deb packages)
>hmm, that is an interesting design, is there more to one your installer
>modules, or is it completely contained in the .so library ?
Sorry, I think I didn't understand you question, so I'll tell you something
about its design:

We currently have an engine, that handles the installation steps, flow control,
etc, and a set of modules (one module from each set of modules):

* imethod modules: knows how to retrieve a file from the distribution (these are
your retriever modules), mounting the necessary support for that. Currently we
only have imethod_local.so module, that knows how to access a file in a mounted
directory (this is because we're still using a patched RedHat's loader, that
already knows how to mount CD-ROMs, NFS, etc). This is one of the things we're
going to change soon (get rid of RH crap).

* target modules: knows everything about where you're going to install.
Currently we only use target_hd.so (for hard disks installations), but I've
implemented target_file.so, so we can be able to install inside a file, via loop
devices. Also, it knows how to install a bootloader, do partitioning,
auto-partitioning, etc (if appliable). There's a flaw in this design: our
"package manager" (pm_* module) writes directly to disk (more on that)

* pkglist modules: knows how to handle a specific package list. We use
pkglist_hdlist.so, that reads the hdlist file from the distribution source (via
imethod module) and understands it, creating a list with package information, so
other modules can use it. Also, it selects/unselects packages.

* pm modules: the package manager. We use pm_rpm.so, that knows how to install a
set of RPM packages, calculate dependencies, verify disk space, and so
on. Currently it ignores the target module, so it can only be used to install in
a local harddisk (we need to patch librpm to use the target_* module or
implement a separate installer). In a near future, we'll be able to drive the
installation in one machine, but actually writing stuff to some other machine
(or a lot of machines, simultaneously) via the network or some other media
already supported by a target_* object.

* distro modules: this module is a "writer" module. It knows how to configure
your system (X, network, etc).

* fe modules: the pluggable interface. An specific API used by the core and all
other modules that supplies both generic methods (showMessage()) and specific
methods (packagsSelection())

>> >Im sure we could find at least some common ground.
>> >
>> Yes! As I told you in the other email, we're redesigning MI core to be much more
>> expandable than it is now, and we'd be very glad in sharing experience with you
>> guys, so we can have the same installer working on RPM-based and DEB-based
>> distros, and maybe FOO-based, BAR-based, BLAH-based, and so on... ;-) If it's
>> Debian's interest adopting MI as it's official installer, rather than developing
>> your own from scratch again, we can put a higher priority on this issue and
>> develop MI's next version altogether. Although this joint development is not an
>> official position from Conectiva, I can assure you from informal conversation
>> that it will be gladly accepted by "my bosses". :-)
>I dont think the new debian-installer will be dumped, its had a lot of
>thought put into it, and things have been moving along fairly quickly in
>the last few weeks although there is still a long way to go.
Yes... I feel sorry for not contacting you before... maybe if I had got known
that you were working on it some time ago, we could have avoided a lot of work
:-) As MI gets mature, maybe you can adopt it as a second-option installer.
Btw, have you tried it already? Maybe you'd like to visit:


or, more specifically:


The former URL is a review of Conectiva 6.0. The latter is the installer's
>I guess a generic installer would be a long term project. Maybe it would
>need to be worked on from people not involved in any specific
>distribution, as i guess we all get blinded by our own ways.
Sure! That's one of the purposes we'd like to have some of you involved, even if
it gets limited to discussing some ideas, as we're doing now :-)


	Luciano Baretta Mandryk
	Conectiva, Inc.

--- End Message ---

Reply to: