Re: Merging Kickstart support from Ubuntu
On Mon, Jan 16, 2006 at 08:13:51PM -0500, Joey Hess wrote:
> Please pardon my probable NIH, but personally, I have never seen the
> point of d-i supporting kickstart files. Surely anyone who is going to
> deploy with that will need to test and fine tune things anyway to make
> an existing kickstart file work with d-i, so I don't see the problem
> with requring they rewrite the file to be a preseed file at the same
> time.
Well, we did it because we had customer requirements for it and it just
made it that bit easier to get into large deployments that already have
a million and one other things to do without rewriting their
preconfiguration files too. Yes, they do have to tweak things a bit, but
with care it can be made to be not too much work.
Don't get me wrong, I like preseeding. It's enormously more flexible
than Kickstart, which only supports whatever the Anaconda designers
decided to put in there rather than practically the entire flow of the
installer. But, for simple configurations, Kickstart does seem to be
easier for some sysadmins to get going, and the fact that it's got quite
a rigid command set makes its files intrinsically pretty robust against
changes in the installer (provided that the implementing code is
adapted, which only has to be done once per installer change). I did try
to allow for the best of both worlds by introducing the preseed command
extension, since it's clear to me that Kickstart just can't do
everything that preseeding can without some much more serious extensions
which really would be NIHing preseed for no particular value.
> As to the 14k, we're currently too big for 32 mb memory installs and
> adding more code to base just makes that even harder to attain again,
> which is more of a concern than size on the floppies which can't really
> support noninteractive installs anyway. If we're going to add code in
> this area it seems to me that using the space for a compatability layer
> to make preseed files work without mods between sarge and etch (etc)
> would be more beneficial.
OK, I can see this argument, and such a compatibility layer would be
very neat. Presumably one could just have a big table of special cases
that's run shortly after env-preseed ...
Acknowledging the space issue, then, how about having kickseed in d-i
svn but not included in images by default? That way, people who want
Kickstart support can get it with a fairly simple initrd rebuild; I
could probably arrange to put suitably-modified i386 daily builds up on
p.d.o.
> > * Mandatory: Kickstart lets you choose to install specific packages as
> > well as package groups (i.e. tasks). Ubuntu has a
> > pkgsel/install-pattern question that can be preseeded with an
> > aptitude pattern, so it's easy there; in Debian, we probably need a
> > similar facility in tasksel.
>
> I'd like to have this regardless, although I'm not sure that exposing it
> as a pattern (rather than a list of packages that is used to construct a
> pattern) is good since patterns can be hard for users to get right,
> especially with packages with "+" in their names.
Yeah, I think using an aptitude pattern was probably a mistake in
retrospect. The reason I did that was because it was a ready-made syntax
that encompassed single packages, tasks, and tasks but with some
packages excluded from them, all of which are expressible in Kickstart
%packages sections; but a simpler and less error-prone syntax could
probably be invented.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: