[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
works.
--- 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:

	http://www.thedukeofurl.org/reviews/misc/conectiva6/

or, more specifically:

	http://www.thedukeofurl.org/reviews/misc/conectiva6/4.shtml

The former URL is a review of Conectiva 6.0. The latter is the installer's
review.
 
>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 :-)

Regargs,

--
	Luciano Baretta Mandryk
	Conectiva, Inc.

--- End Message ---
Reply to: