/lib/modules/$(KERNELVER)/kernel/drivers/sensors left empty

/lib/modules/$(KERNELVER)/kernel/drivers/sensors left empty

[Jean Delvare]

Hi,

I noticed that when upgrading from an old lm_sensors to CVS, modules are
installed to /lib/modules/$(KERNELVER)/kernel/drivers/i2c instead of
/lib/modules/$(KERNELVER)/kernel/drivers/sensors. Old modules are
removed, but the directory itself isn't. Shouldn't we delete it as well?
Or could possibly be there something that doesn't belong to us?

Also, modules are removed if and only if they are uncompressed. .o.gz
(do .o.bz2 exist?) modules are not. I know we don't compress modules,
but maybe removing any existing module could solve possible issues
before they arise. Comments on this would be welcome.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

/lib/modules/$(KERNELVER)/kernel/drivers/sensors left empty

[Mark D. Studebaker]

good questions.
I don't know if either problem is worth solving.
The first problem is harmless but the second one could cause trouble.
What installation procedure compresses modules - it is a Red Hat thing or something?
How common is this?

Jean Delvare wrote:
> Hi,
> 
> I noticed that when upgrading from an old lm_sensors to CVS, modules are
> installed to /lib/modules/$(KERNELVER)/kernel/drivers/i2c instead of
> /lib/modules/$(KERNELVER)/kernel/drivers/sensors. Old modules are
> removed, but the directory itself isn't. Shouldn't we delete it as well?
> Or could possibly be there something that doesn't belong to us?
> 
> Also, modules are removed if and only if they are uncompressed. .o.gz
> (do .o.bz2 exist?) modules are not. I know we don't compress modules,
> but maybe removing any existing module could solve possible issues
> before they arise. Comments on this would be welcome.
> 

/lib/modules/$(KERNELVER)/kernel/drivers/sensors left empty

[Jean Delvare]

> > I noticed that when upgrading from an old lm_sensors to CVS, modules
> > are installed to /lib/modules/$(KERNELVER)/kernel/drivers/i2c
> > instead of/lib/modules/$(KERNELVER)/kernel/drivers/sensors. Old
> > modules are removed, but the directory itself isn't. Shouldn't we
> > delete it as well? Or could possibly be there something that doesn't
> > belong to us?
> > 
> > Also, modules are removed if and only if they are uncompressed.
> > .o.gz(do .o.bz2 exist?) modules are not. I know we don't compress
> > modules, but maybe removing any existing module could solve possible
> > issues before they arise. Comments on this would be welcome.
>
> good questions.
> I don't know if either problem is worth solving.
> The first problem is harmless but the second one could cause trouble.
> What installation procedure compresses modules - it is a Red Hat thing
> or something? How common is this?

On the other hand, both problem are easy to fix, methinks (yeah, you
always say that *before* trying, and only later understand how painful
it will be).

For the empty directory thing, I suggest one of the following solutions:
1* "rmdir --ignore-fail-on-non-empty $DIR". It's clean, but will fail
before fileutils-4.0.
2* "rmdir $DIR 2> /dev/null || true". Does the same, will work
everywhere.
3* "if [ "$(ls -A $dir)" = '' ] ; then rmdir $dir ; fi". Probably
cleaner than 2*, more flexible (we can add a warning if the directory
isn't empty) but slower.
My preference go to 2*. Simple and efficient.

Compressing modules is a common practice among distributions. Slackware
does it (that's why I noticed the problem), I was told Mandrake does it
too, but Debian and Red Hat wouldn't. I think there are only few risks
this ever cause a problem because a non-compressed (that is, our) module
will be prefered over a compressed (that is, their) module. But anyway,
removing the old modules frees some disk space, and probably quickens
subsequent depmods. And removing compressed modules is rather easy, so I
think we should do it.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

/lib/modules/$(KERNELVER)/kernel/drivers/sensors left empty

[Mark D. Studebaker]

I put gz removal and directory solution #2 in both sensors and i2c.
please test.

Jean Delvare wrote:
>>>I noticed that when upgrading from an old lm_sensors to CVS, modules
>>>are installed to /lib/modules/$(KERNELVER)/kernel/drivers/i2c
>>>instead of/lib/modules/$(KERNELVER)/kernel/drivers/sensors. Old
>>>modules are removed, but the directory itself isn't. Shouldn't we
>>>delete it as well? Or could possibly be there something that doesn't
>>>belong to us?
>>>
>>>Also, modules are removed if and only if they are uncompressed.
>>>.o.gz(do .o.bz2 exist?) modules are not. I know we don't compress
>>>modules, but maybe removing any existing module could solve possible
>>>issues before they arise. Comments on this would be welcome.
>>
>>good questions.
>>I don't know if either problem is worth solving.
>>The first problem is harmless but the second one could cause trouble.
>>What installation procedure compresses modules - it is a Red Hat thing
>>or something? How common is this?
> 
> 
> On the other hand, both problem are easy to fix, methinks (yeah, you
> always say that *before* trying, and only later understand how painful
> it will be).
> 
> For the empty directory thing, I suggest one of the following solutions:
> 1* "rmdir --ignore-fail-on-non-empty $DIR". It's clean, but will fail
> before fileutils-4.0.
> 2* "rmdir $DIR 2> /dev/null || true". Does the same, will work
> everywhere.
> 3* "if [ "$(ls -A $dir)" = '' ] ; then rmdir $dir ; fi". Probably
> cleaner than 2*, more flexible (we can add a warning if the directory
> isn't empty) but slower.
> My preference go to 2*. Simple and efficient.
> 
> Compressing modules is a common practice among distributions. Slackware
> does it (that's why I noticed the problem), I was told Mandrake does it
> too, but Debian and Red Hat wouldn't. I think there are only few risks
> this ever cause a problem because a non-compressed (that is, our) module
> will be prefered over a compressed (that is, their) module. But anyway,
> removing the old modules frees some disk space, and probably quickens
> subsequent depmods. And removing compressed modules is rather easy, so I
> think we should do it.
>