Bug#66578: FWD: Re: Bug#66578: Module descriptions in modconf

[Randolph Chung <tausq@debian.org>]

sent to me privately

----- Forwarded message from Niccolo Rigacci <rigacci@iname.com> -----

Date: Sun, 02 Jul 2000 09:15:08 +0200
From: "Niccolo Rigacci" <rigacci@iname.com>
To: "Randolph Chung" <tausq@debian.org>
Subject: Re: Bug#66578: Module descriptions in modconf

Randolph Chung wrote:
> 
> As the de facto package maintainer I will be the first to admit that the
> status of the module messages is totally ridiculous.

Very happy to hear from you so quickly!

I'd like to release something better, but we are in freeze. Do
you think we can add some files to the package? I mean a README
with some guidelines like that:


README for modconf-0.2.26.14
-------------------------------
How to add/fix description for modules.

Modconf (once compiled) looks for descriptions of modules in
/usr/share/modconf/descr.gz and /usr/share/modconf/eval_* (is it
OK? In what order? When it uses localized versions?).

Those files are builded by the scripts mkdescr.pl and
debian/mkkerneldesc.pl during the "make descr.gz" phase (is that
all?). Those scripts look in the following places for guessing
descriptions:

- Your kernel tree supposed to live in /usr/src/linux/
- The Module-HOWTO.gz (a little outdated doc)
- The descr.additional and template/eval_*.fixed files
- Is that all? Is the order correct?

Because the latter files override previous methods, if you want
to add/fix descriptions for some modules do the following:

- Add a brief description (n chars) of the modules in
  template/eval_C.fixed and the localized version in
  eval_xx.fixed only if really needed.
- Add a section for that module in descr.additional. This section
  is organized as follow...
- I guessed it OK? I fear not, because I was unable to generate
  an unique summary_lp="...." in eval_C :-(



I hope this is possible.
With that guideline, adding/fixing descriptions become quick and
feasible for me and form many other people, without breaking the
freeze status.

I think that this is not the "right thing" to do: it would be
better to develop a totally automated procedure that look in the
sources and magically do the rest. But manual work can assure
that at least very popular modules will be well documented.


-----

Just another question.

Do you know why lp.o is not correctly modprobed during the potato
install? I need to insmod parport_pc manually, otherwise lp wont
load. Both in modconf or via command line in another shell.

After the base system is installed, modprobe correctly loads lp.o
along with parport.o and parport_pc.o instead.

I discussed it on debian-boot, but not filled a bug report yet.



Niccolo Rigacci
Firenze - Italy



----- End forwarded message -----

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/