Re: ABI change in libsensors1 (from lm-sensors)
Why not kick upstream into releasing 2.7.1 with proper soname bump to libsensors2 (Make sure they are aware they screwed up...). Then upload libsensors2, there are only 8 sources depending on libsensors1 now so it wouldn't be a big deal to rebuild those few in any case. Chris sources depending on libsensors1 hardware-monitor kdebase ksensors lm-sensors mrtgutils wmgtemp wmsensors xsensors
Re: ABI change in libsensors1 (from lm-sensors)
Chris Cheney [EMAIL PROTECTED] writes: Why not kick upstream into releasing 2.7.1 with proper soname bump to libsensors2 (Make sure they are aware they screwed up...). Then upload libsensors2, there are only 8 sources depending on libsensors1 now so it wouldn't be a big deal to rebuild those few in any case. I did send upstream mail pointing out the issue and asking for an soname change, but I haven't heard anything back. I'll upload a new package with a Debian-specific soname as soon as I can get to a development machine with the relevant hardware, probably tomorrow... sources depending on libsensors1 hardware-monitor kdebase ksensors lm-sensors mrtgutils wmgtemp wmsensors xsensors (The other motivation for uploading a new libsensors1 is to Conflict: with the subset of these packages that have linked against the libsensors1 that doesn't work; if I'm not going to do that, then I should probably ask that libsensors1 be removed.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: ABI change in libsensors1 (from lm-sensors)
On Tue, May 13, 2003 at 01:32:02PM -0400, David Z Maze wrote: Steve Langasek [EMAIL PROTECTED] writes: On Mon, May 12, 2003 at 01:45:30PM -0400, David Z Maze wrote: (a) Repackaging lm-sensors 2.6.5, which would just have libsensors1 1:2.6.5-1, which in turn would Conflict: with any packages that have compiled against libsensors1 2.7.0 (AFAIK, just one). (b) Changing the soname of libsensors.so to libsensors.so.1.debian.1 in lm-sensors 2.7.0, and changing the name of the library package to libsensors-1debian1, and changing the shlibs file appropriately. (c) Checking that the user-kernel interface hasn't changed; that is, that the 2.6.5 library works vs. 2.7.0 modules, and vice versa. Is this a reasonable course of action? The soname feels a little ugly to me, but otherwise, assuming (c), it does feel like about the right thing to do. You're talking about doing all of the above? If you do (b) and (c), why do you still need to do (a)? (I.e., why would you maintain two versions of the library in unstable simultaneously?) Doing (b) and (c) seems reasonable, at least. But if you don't have kernel interface issues from (c), I don't see why you would want (a). I'd like packages that haven't recompiled vs. libsensors-1debian1 to still work. (a) would mean providing the old libsensors1 with the old ABI, which would enable this. (If (c) works and I do (b) but not (a), then the lm-sensors source package now provides libsensors-dev and libsensors-1debian1, and nothing provides libsensors1.) So you intend to maintain two versions of this library for the duration of a stable release cycle? That doesn't seem like a good idea to me. Otherwise, this is a standard library soname migration, and the sooner other packages stop depending on the older lib, the better, IMHO. -- Steve Langasek postmodern programmer pgpp2owTzgDU6.pgp Description: PGP signature
Re: ABI change in libsensors1 (from lm-sensors)
Steve Langasek [EMAIL PROTECTED] writes: On Mon, May 12, 2003 at 01:45:30PM -0400, David Z Maze wrote: (a) Repackaging lm-sensors 2.6.5, which would just have libsensors1 1:2.6.5-1, which in turn would Conflict: with any packages that have compiled against libsensors1 2.7.0 (AFAIK, just one). (b) Changing the soname of libsensors.so to libsensors.so.1.debian.1 in lm-sensors 2.7.0, and changing the name of the library package to libsensors-1debian1, and changing the shlibs file appropriately. (c) Checking that the user-kernel interface hasn't changed; that is, that the 2.6.5 library works vs. 2.7.0 modules, and vice versa. Is this a reasonable course of action? The soname feels a little ugly to me, but otherwise, assuming (c), it does feel like about the right thing to do. You're talking about doing all of the above? If you do (b) and (c), why do you still need to do (a)? (I.e., why would you maintain two versions of the library in unstable simultaneously?) Doing (b) and (c) seems reasonable, at least. But if you don't have kernel interface issues from (c), I don't see why you would want (a). I'd like packages that haven't recompiled vs. libsensors-1debian1 to still work. (a) would mean providing the old libsensors1 with the old ABI, which would enable this. (If (c) works and I do (b) but not (a), then the lm-sensors source package now provides libsensors-dev and libsensors-1debian1, and nothing provides libsensors1.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
