custom installers [LWN.net]

custom installers

Posted Aug 6, 2004 11:39 UTC (Fri) by Duncan (guest, #6647)
In reply to: custom installers by edstoner
Parent article: A look at Gentoo 2004.2

It's /possible/ with other distributions. I know it was certainly
possible with Mandrake, and it should be possible for /some/ definition of
the term for any distribution with an open source installer, since one can
in theory simply modify the installer source as desired and
recompile/reconstruct the config from there.

On Mandrake, it was fairly easy to redefine which packages were available
on which CDs, and what each application group would install. Mandrake's
rather excellent urpmi dependency system (based on the perl URPM module
functionality) helped in this regard a great deal.

The catch, of course, is that at that, the simplest level, one is still
installing Mandrake generated packages with Mandrake generated dependency
decisions (parallel to Gentoo's USE flags, only at this point set up by
the distribution), limiting the flexibility to some extent.

Mandrake being an RPM/SRPM distribution, the next step beyond that would
be downloading the SRPMs and recompiling them into your own RPM packages.
The caveat here is that we are VERY quickly getting into poorly documented
territory. Altho the RPM commands for working with source themselves are
fairly standard, there's no parallel to the ease of finding USE flags on
Gentoo. Many of the possible configure options for rebuilding the srpms
with the various options and dependencies are ENTIRELY undocumented,
unless one wishes to go looking at the spec files and package config
scripts themselves, going deep into knowing and understanding the
component code, rather than just issuing a command and getting available
options along with their current status, as is the Gentoo way.

The ONE thing that continues to impress me about Gentoo, and it's already
been mentioned, is the sheer availability of the necessary information for
doing many of the out of the lowest common denominator tasks. That is,
there's very few distributions (if any) that even come CLOSE to Gentoo in
the documentation area. Not only is the above far easier to do without
"deep code diving" in Gentoo than elsewhere, as mentioned, but the info
about how to actually DO it is actually THERE! One doesn't have to "just
do it", and /hope/ they get it right, as I found so often the case on
Mandrake.

Duncan

(Log in to post comments)

"How do you want to waste the day?" -- yeah it's Gentoo!

Posted Aug 18, 2004 19:43 UTC (Wed) by gvy (guest, #11981) [Link]

> Mandrake's rather excellent urpmi dependency system

Oh no, not that again.

urpmi clearly sucks -- it will eagerly plug you packages with mutual Conflicts: tags :(

Conectiva's apt port is much closer to a workable solution. ALT Linux 3 is rumoured to be dropping Mdk's installer remnants altogether and moving to total apt'ification of the process, which is a Good Thing(TM) -- fixing the guts of pixel's chedeur (especially older versions) is what drove me mad, even not being really active on that.

---

On the topic of USE flags, modern package repos tend to have weighs of %def_with, %if_with and tags like that in specs so that you can rebuild a package in quite distracted manner as opposed to focused spec hacking. =)

---

I personally don't like Gentoo since it drives people being closely locked up in their localhosts, hardly being able to support larger numbers of systems which is essential to lowering the costs of running the systems. Yeah, there are many factors and tweaks but somehow a person able to do the trick with source-based distro is more productive at "real tasks" with a little help from package-based power tools, and person realizing the weaknesses of pre-packaging approach is able to get around them just as easily most of the time.

It's the same reason I don't like Slackware for -- you just can't offer jobs to people spoiled by that as "The Only Distro" as you can't rely on the resulting mess to be supportable.

Gentoo is much more organized, but the idea of having C compiler and kernel headers on *production* servers just doesn't help the fact you have to administer your own package repo otherwise (or have no advantage in face of packaged solutions).

But the docs are nice, that's true. Just as the buzz and Dan's PR is.