[PATCH 1/2] UBUNTU: (packaging) Resolve module dependencies in base package

Andy Whitcroft apw at canonical.com
Wed Apr 10 10:10:51 UTC 2013


On Tue, Apr 09, 2013 at 12:17:50PM -0600, Tim Gardner wrote:
> On 04/09/2013 12:04 PM, Scott Moser wrote:
> > On Tue, 9 Apr 2013, Stefan Bader wrote:
> > 
> >> It turns out that there are several modules in the base package which
> >> have unmet dependencies on modules in the extra package. This change
> >> will move the following:
> >>
> >>   72K drivers/char/ipmi/ipmi_msghandler.ko
> >>  612K drivers/infiniband/core/*
> >>  104K drivers/scsi/device_handler/*
> >>   72K drivers/scsi/osd/*
> >>   32K fs/exofs/libore.ko
> >>  200K net/ceph/libceph.ko
> >> -----
> >> 1092K
> > 
> > Stefan,
> >   Thanks for looking at this.
> > 
> >> The numbers are taken from a 64bit build, so should be worst case. The
> >> resulting linux-image package was 7.1M.
> > 
> > Where did you get 7.1M?
> > 
> > $ apt-cache show linux-image-3.8.0-17-generic | grep Size
> > Installed-Size: 33020
> > Size: 12539448
> > 
> > Not a big deal, if anything it lessens the effect of including these
> > dependencies.  As we're proposing to grow a ~33M installed package by ~1M.
> > 
> > I have 2 thoughts here:
> > a.) If we've made due with out these modules in the base image, then
> >     perhaps we could take the opposite approach and trim out the broken
> >     modules from the base image and *reduce* its size.  That clearly would
> >     not cause regression as people were not [successfully] using those
> >     modules anyway.
> > 
> 
> I'm inclined to take this approach, e.g., remove from linux-image all
> modules with unsatisfied dependencies (after first fixing ceph).
> 
> >     If someone wants these specific modules back in, they can file bugs
> >     and request such things.
> > 
> > b.) We really should have some document or guiding policy on what function
> >     gets included in base and what does not.  Otherwise the kernel team is
> >     left to my whimsy of "please put module X in -virtual" without any
> >     good reasoning or justification for refusal.
> > 
> 
> Mostly our policy to date has consisted of me dragging my feet and
> resisting inclusion requests. The virtual image definition was never
> really very well defined.

With the overarching "if you really need that module it is now in -extras
so just install that and be happy" which has helped people not ask for
new things in -virtual.  I suspect that a good sprint thing would be to
review what is in the base package and see if there are any further
things we can eject.

-apw




More information about the kernel-team mailing list