[lm-sensors] lm-sensors-3.0.0 and /etc/sensors.conf [was:

[lm-sensors] lm-sensors-3.0.0 and /etc/sensors.conf [was:

[Hans de Goede]

Hi All,

In another thread Jean Delvare wrote:

---

 > However I have a remark to ease the transition from version 2.x.x to
 > version 3.0.0: it is currently possible to have the two libraries
 > installed, but they both use the same configuration file. What about
 > having different config files for the two versions (e.g. sensors.conf
 > and sensors3.conf) ?

Technically speaking, the libraries themselves don't have default
configuration files. Applications do. That makes the matter only worse.

For openSuse, my plan was to get plain rid of lm-sensors 2 and all
applications using it as soon as possible, so that no such conflict
happens. I don't think we'll package libsensors v2.10.x in the next
release. I don't know what Hans' plans are for Fedora. Of course, if
you intend to guarantee backwards compatibility by shipping the old
libsensors for a longer time in Debian, then indeed you have a problem.

The fact that applications, rather than the library, set the default
configuration file name, means that it's essentially out of our control.
We could change sensors and sensord in lm-sensors 3.0.0 to use a
different default, but that won't solve the problem for all the 3rd
party applications out there. You'd need to change them all. Either the
authors do, or the packagers will have to.

If you want to use /etc/sensors3.conf as the default for applications
using lm-sensors 3 in Debian, there's nothing preventing you from doing
that. This doesn't really have to be done upstream. That being said, I
agree that it would become confusing if different distributions come up
with different naming schemes.

Coming to think about it, I think it's silly to have the default
configuration file name in applications. There's really no reason why
an application would want to use a different default, is there? So it
might be the right time to change this and put the default
configuration file name in libsensors. Calling sensors_init(NULL) would
use that default. It would make it easier to change the default if a
distribution wants to, and it would enforce a common default for
applications using the new library. Opinions?

I don't much like the idea of using /etc/sensors3.conf for lm-sensors
3. Soon enough, lm-sensors 2 will be history, sensors.conf will no
longer exist, and we'll be stuck with /etc/sensors3.conf. That's a bit
unaesthetic, isn't it? A slightly different approach would be to
use /etc/sensors3.conf if it exists, and /etc/sensors.conf otherwise
(as was done for the XFree86 configuration file from version 3.x to
version 4.x; remember?) This approach preserves compatibility with
existing installations and offers a nice upgrade path. But of course
this can only be (easily) implemented if the default is handled in
libsensors rather than in the applications themselves, as I proposed
above.

---

My vote goes to removing the configfile argument to sensors_init, and hardcode
/etc/sensors.conf in libsensors. Then we can make this /etc/sensors3.conf for
lm-sensors-3.x.x so that the 2 libs can be installed in parallel for distro's
who want to have a compatibility lib for the old 2.x version.

I agree that having /etc/sensors3.conf isn't pretty, but it isn't horrible 
either, so I think its a good compromise.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors-3.0.0 and /etc/sensors.conf [was:

[Jean Delvare]

Hi Hans,

On Wed, 24 Oct 2007 11:40:18 +0200, Hans de Goede wrote:
> Hi All,
> 
> In another thread Jean Delvare wrote:
> 
> ---
> 
>  > However I have a remark to ease the transition from version 2.x.x to
>  > version 3.0.0: it is currently possible to have the two libraries
>  > installed, but they both use the same configuration file. What about
>  > having different config files for the two versions (e.g. sensors.conf
>  > and sensors3.conf) ?
> 
> Technically speaking, the libraries themselves don't have default
> configuration files. Applications do. That makes the matter only worse.
> 
> For openSuse, my plan was to get plain rid of lm-sensors 2 and all
> applications using it as soon as possible, so that no such conflict
> happens. I don't think we'll package libsensors v2.10.x in the next
> release. I don't know what Hans' plans are for Fedora. Of course, if
> you intend to guarantee backwards compatibility by shipping the old
> libsensors for a longer time in Debian, then indeed you have a problem.
> 
> The fact that applications, rather than the library, set the default
> configuration file name, means that it's essentially out of our control.
> We could change sensors and sensord in lm-sensors 3.0.0 to use a
> different default, but that won't solve the problem for all the 3rd
> party applications out there. You'd need to change them all. Either the
> authors do, or the packagers will have to.
> 
> If you want to use /etc/sensors3.conf as the default for applications
> using lm-sensors 3 in Debian, there's nothing preventing you from doing
> that. This doesn't really have to be done upstream. That being said, I
> agree that it would become confusing if different distributions come up
> with different naming schemes.
> 
> Coming to think about it, I think it's silly to have the default
> configuration file name in applications. There's really no reason why
> an application would want to use a different default, is there? So it
> might be the right time to change this and put the default
> configuration file name in libsensors. Calling sensors_init(NULL) would
> use that default. It would make it easier to change the default if a
> distribution wants to, and it would enforce a common default for
> applications using the new library. Opinions?
> 
> I don't much like the idea of using /etc/sensors3.conf for lm-sensors
> 3. Soon enough, lm-sensors 2 will be history, sensors.conf will no
> longer exist, and we'll be stuck with /etc/sensors3.conf. That's a bit
> unaesthetic, isn't it? A slightly different approach would be to
> use /etc/sensors3.conf if it exists, and /etc/sensors.conf otherwise
> (as was done for the XFree86 configuration file from version 3.x to
> version 4.x; remember?) This approach preserves compatibility with
> existing installations and offers a nice upgrade path. But of course
> this can only be (easily) implemented if the default is handled in
> libsensors rather than in the applications themselves, as I proposed
> above.
> 
> ---
> 
> My vote goes to removing the configfile argument to sensors_init, and hardcode
> /etc/sensors.conf in libsensors.

I don't like this. While I do agree that most applications shouldn't
use this parameter, it is still very convenient to be able to do
"sensors -c <something>" as a user to test a custom configuration file
before you copy that file to /etc/sensors.conf (or whatever it will
be.) Also, being able to ask the users to report the output of sensors
with no configuration file interfering (sensors -c /dev/null) is very
valuable for debugging and investigating, and I wouldn't want to lose
this ability.

There seems to be a consensus on the fact that the default should be in
libsensors and not in the applications though, so I can implement this
now.

>                                  Then we can make this /etc/sensors3.conf for
> lm-sensors-3.x.x so that the 2 libs can be installed in parallel for distro's
> who want to have a compatibility lib for the old 2.x version.
> 
> I agree that having /etc/sensors3.conf isn't pretty, but it isn't horrible 
> either, so I think its a good compromise.

My proposal to use /etc/sensors3.conf if present and fall back
to /etc/sensors.conf if not, achieves this as well. Do you see any
reason not to do this?

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] lm-sensors-3.0.0 and /etc/sensors.conf [was:

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Wed, 24 Oct 2007 11:40:18 +0200, Hans de Goede wrote:
>> Hi All,
>>
>> In another thread Jean Delvare wrote:
>>
>> ---
>>
>>  > However I have a remark to ease the transition from version 2.x.x to
>>  > version 3.0.0: it is currently possible to have the two libraries
>>  > installed, but they both use the same configuration file. What about
>>  > having different config files for the two versions (e.g. sensors.conf
>>  > and sensors3.conf) ?
>>
>> Technically speaking, the libraries themselves don't have default
>> configuration files. Applications do. That makes the matter only worse.
>>
>> For openSuse, my plan was to get plain rid of lm-sensors 2 and all
>> applications using it as soon as possible, so that no such conflict
>> happens. I don't think we'll package libsensors v2.10.x in the next
>> release. I don't know what Hans' plans are for Fedora. Of course, if
>> you intend to guarantee backwards compatibility by shipping the old
>> libsensors for a longer time in Debian, then indeed you have a problem.
>>
>> The fact that applications, rather than the library, set the default
>> configuration file name, means that it's essentially out of our control.
>> We could change sensors and sensord in lm-sensors 3.0.0 to use a
>> different default, but that won't solve the problem for all the 3rd
>> party applications out there. You'd need to change them all. Either the
>> authors do, or the packagers will have to.
>>
>> If you want to use /etc/sensors3.conf as the default for applications
>> using lm-sensors 3 in Debian, there's nothing preventing you from doing
>> that. This doesn't really have to be done upstream. That being said, I
>> agree that it would become confusing if different distributions come up
>> with different naming schemes.
>>
>> Coming to think about it, I think it's silly to have the default
>> configuration file name in applications. There's really no reason why
>> an application would want to use a different default, is there? So it
>> might be the right time to change this and put the default
>> configuration file name in libsensors. Calling sensors_init(NULL) would
>> use that default. It would make it easier to change the default if a
>> distribution wants to, and it would enforce a common default for
>> applications using the new library. Opinions?
>>
>> I don't much like the idea of using /etc/sensors3.conf for lm-sensors
>> 3. Soon enough, lm-sensors 2 will be history, sensors.conf will no
>> longer exist, and we'll be stuck with /etc/sensors3.conf. That's a bit
>> unaesthetic, isn't it? A slightly different approach would be to
>> use /etc/sensors3.conf if it exists, and /etc/sensors.conf otherwise
>> (as was done for the XFree86 configuration file from version 3.x to
>> version 4.x; remember?) This approach preserves compatibility with
>> existing installations and offers a nice upgrade path. But of course
>> this can only be (easily) implemented if the default is handled in
>> libsensors rather than in the applications themselves, as I proposed
>> above.
>>
>> ---
>>
>> My vote goes to removing the configfile argument to sensors_init, and hardcode
>> /etc/sensors.conf in libsensors.
> 
> I don't like this. While I do agree that most applications shouldn't
> use this parameter, it is still very convenient to be able to do
> "sensors -c <something>" as a user to test a custom configuration file
> before you copy that file to /etc/sensors.conf (or whatever it will
> be.) Also, being able to ask the users to report the output of sensors
> with no configuration file interfering (sensors -c /dev/null) is very
> valuable for debugging and investigating, and I wouldn't want to lose
> this ability.
> 
> There seems to be a consensus on the fact that the default should be in
> libsensors and not in the applications though, so I can implement this
> now.
> 
>>                                  Then we can make this /etc/sensors3.conf for
>> lm-sensors-3.x.x so that the 2 libs can be installed in parallel for distro's
>> who want to have a compatibility lib for the old 2.x version.
>>
>> I agree that having /etc/sensors3.conf isn't pretty, but it isn't horrible 
>> either, so I think its a good compromise.
> 
> My proposal to use /etc/sensors3.conf if present and fall back
> to /etc/sensors.conf if not, achieves this as well. Do you see any
> reason not to do this?
> 

No not all, I should have more verbose on that, checking for /etc/sensors3.conf 
first and then /etc/sensors.conf, when the sensors_init argument is NULL, 
sounds like a good plan to me.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors