Re: [D-I] Supporting 2.6.14 kernels in base-installer
(Forwarding replies to the yaird-devel list)
On Mon, Nov 14, 2005 at 09:21:38PM +0100, Sven Luther wrote:
> On Mon, Nov 14, 2005 at 03:17:24PM -0500, Joey Hess wrote:
> > Sven Luther wrote:
> > > Also, we have perl-base in base, or used to at least, would yaird not be able
> > > to depend on perl-base only ?
> >
> > yaird uses at lest the following perl modules which are not currently
> > present in perl-base but are in perl:
>
> > ./Image.pm:use File::Copy;
> > ./Pack.pm:use File::Temp;
> >
> > On the one hand, perl-base exists to provide the perl modules needed by
> > packages in the Debian base system, so if a package like debconf or so
> > needs a specific module, it can be moved from perl to that package. If
> > yaird becomes part of the base system, or close enough to be needed to
> > fit on Debian netinst CDs (which is pretty much the same thing), then
> > adding the modules it needs to perl-base should not be a problem. perl's
> > maintainer is very helpful about these things in my experience.
> >
> > On the other hand, the use of File::Copy is trivially replaced by a
> > system() call. I'd be careful replacing the File::Temp usages with
> > something else though.
Agreed.
> > It also uses HTML::Template and Parse::Recdescent that are in separate
> > packages. From what I can see of the config files, using
> > Parse::Recdescent to parse them is overkill; it should be possible to
> > write a parser by hand pretty easily. The use of HtmlTemplate is quite
> > strange.
Parse::RecDescent: the information in the config file is a bit too much
for the perl AppConfig module, you will need a parser. I agree that a
parser could be hand written, and it would be smaller than what RecDescent
does, if only because you don't need to include a parser-generator,
just a parser. The .deb for RecDescent is only 88k, but it sucks in perl
rather than perl-base. What that buys you is years of testing plus good
error reporting. It's a tradeoff.
HtmlTemplate: two aspects here:
(1) _html_ template? The html is accidental, this just happens to be the
best templating package around, for our purposes at least. Think of it
as a generic template package that happens to have pointy brackets as
escape notation.
(2) But why templating at all? The basic premise is that yaird provides
analysis code (in perl) and we want tunable behaviour based on that
analysis: putting stuff on the image, where it should be possible to
experiment with the stuff on image, without understanding every last
detail of the perl code.
There are a lot of ways to make it tunable:
-- callbacks invoked by the analysis modules,
-- data structures returned by analysis modules, then interpreted
to put stuff on the image
-- or templates
The templating approach has the advantage of a clean separation between
layers: when writing eg an LVM analysis module, you don't have to think
about side effects in templates used; the template system is guaranteed
to be side effect free. Conversely, when writing a template, the information
available to the template and the allowed syntax is pretty obvious.
The templating approach seems to be approximately the simplest one that is
expressive enough; personally, I find the ugliest bits of yaird are in
the top level config, more than in the bottom level templates.
As with the parser, you could roll your own which would be smaller
than the generic one, but the first releases would not have the
stability and documentation that comes with years of polishing.
> I think the best would be for Erik to comment on this, CCing this to him now.
To summarise: we can reduce dependencies and make the footprint smaller,
but at a cost in building effort and the stability that comes with
mature packages. A consequence is that it would take longer to build
new features such as swsusp. It's a tradeoff; I would appreciate input
on which aspect is most important for etch.
Regards,
Erik
Reply to: