--- Begin Message ---
On Sat, Apr 30, 2011 at 10:25:23PM +0200, Alexander Wuerstlein wrote:
> On 11-04-30 21:44, maximilian attems <maks@debian.org> wrote:
> > tags 624699 moreinfo
> > stop
> >
> > On Sat, Apr 30, 2011 at 08:23:14PM +0200, Alexander Wuerstlein wrote:
> > > Package: initramfs-tools
> > > Version: 0.98.8
> > > Severity: wishlist
> > >
> > >
> > > Include an option MODULES=all which includes the complete
> > > /lib/modules/${version} subtree of the filesystem.
> >
> > this needs a very good reason.
>
> It would be simpler to use and less prone to user errors and software
> problems. Also, I see no good reason to use MODULES=most when the size
> of the initrd is not important, MODULES=all would have a far simpler
> semantic, which makes it far easier to understand, debug and use.
>
> Please note that I do not suggest making MODULES=all the default.
MODULES=most is there to have an general initramfs that should just
work out of the box, if it doesn't than this is a bug and needs to
be reported.
we won't add a third option that is not supportable.
first of all big initramfs -> slow boot consequence
secondly you don't necessarly want drm in initramfs
third if you go down your road you may argue to add X to initramfs.
>
> The primary reason that triggered the idea that MODULES=all would be a
> good addition was bug no. 624692
that is circular reasoning.
> Also MODULES=most excludes certain parts, for example the "net" part
> excludes "appletalk arcnet bonding can hamradio irda pcmcia tokenring
> usb wan wimax wireless". If I need one or more of those modules in my
> image, I need to manually override those exceptions. For one or two
> modules that is fine, but for tasks like "support that for all the
> hardware we use anywhere around here" that list grows and is tedious to
> maintain.
report a bug for the specific module that may have been missing in your
case. don't overgeneralise.
> MODULES=all does not need any of that maintenance. Also, it
> eliminates the need for the elaborate and error-prone dependency
> resolution that MODULES=most needs, therefore making it very robust,
> useful for debugging ("why doesn't it boot, is there a module
> missing?") and an easy workaround should MODULES=most be broken for some
> reason.
every option adds maintenance and bugs. as told above I don't want any
of those, so this proposal is disguarded.
> I have to admit though, that I'm not sure if there are any downsides
> besides the obviously larger resulting initrd.
>
thank you
--
maks
--- End Message ---