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

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

The numbers are taken from a 64bit build, so should be worst case. The
resulting linux-image package was 7.1M.

BugLink: http://bugs.launchpad.net/bugs/1164739

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 debian.master/control.d/generic.inclusion-list |    6 ++++++
 1 file changed, 6 insertions(+)

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.

    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.

> BugLink: http://bugs.launchpad.net/bugs/1164739
>
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  debian.master/control.d/generic.inclusion-list |    6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/debian.master/control.d/generic.inclusion-list b/debian.master/control.d/generic.inclusion-list
> index 00d9911..c30f821 100644
> --- a/debian.master/control.d/generic.inclusion-list
> +++ b/debian.master/control.d/generic.inclusion-list
> @@ -9,11 +9,13 @@ drivers/block/nbd.ko
>  drivers/block/floppy.ko
>  drivers/block/cryptoloop.ko
>  drivers/char/hangcheck-timer.ko
> +drivers/char/ipmi/ipmi_msghandler.ko
>  drivers/char/lp.ko
>  drivers/char/nvram.ko
>  drivers/char/ppdev.ko
>  drivers/char/raw.ko
>  drivers/hv/*
> +drivers/infiniband/core/*
>  drivers/input/evbug.ko
>  drivers/input/gameport/gameport.ko
>  drivers/input/mouse/psmouse.ko
> @@ -54,10 +56,12 @@ drivers/parport/parport_pc.ko
>  drivers/pci/hotplug/acpiphp.ko
>  drivers/net/ethernet/dec/tulip/*
>  drivers/scsi/BusLogic.ko
> +drivers/scsi/device_handler/*
>  drivers/scsi/iscsi_tcp.ko
>  drivers/scsi/libiscsi.ko
>  drivers/scsi/libiscsi_tcp.ko
>  drivers/scsi/libsas/*
> +drivers/scsi/osd/*
>  drivers/scsi/qla1280.ko
>  drivers/scsi/raid_class.ko
>  drivers/scsi/scsi_transport_fc.ko
> @@ -87,6 +91,7 @@ fs/btrfs/*
>  fs/cachefiles/cachefiles.ko
>  fs/ceph/*
>  fs/configfs/*
> +fs/exofs/libore.ko
>  fs/ext*/*
>  fs/fat/*
>  fs/nls/nls_cp437.ko
> @@ -113,6 +118,7 @@ net/atm/*
>  net/ax25/*
>  net/bridge/*
>  net/can/*
> +net/ceph/libceph.ko
>  net/core/*
>  net/dccp/*
>  net/decnet/*
> --
> 1.7.9.5
>
>

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.

rtg

Kind of. I fixed a couple dependencies (9p and dm-multipath) and removed
a couple others (acpi-ipmi and nfs objectlayoutdriver).

rtg

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