Jean Delvare a ?crit : Hi Jean, >> 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. I agree that the library itself doesn't have any default. However, the scripts in the source tarball install the configuration file as sensors.conf > 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. I still don't know if we want to support backward compatibility in Debian, but we have a lot more applications to port, so I don't know how long it will take. > 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. Yes I agree the code can be changed, and having a common policy for all distributions is a good point for the users. > 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? Looks like a really good idea, I vote for it. > 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. I think it is a good option. In case it is chosen, I advise to explain that in the doc, otherwise the users may be confused. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32 at debian.org | aurelien at aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net
