Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Fri, Sep 07, 2001 at 12:09:39PM +0200, Christian Marillat wrote: DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) Yes, but see libgal or gtkhtml. A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? In that case the shlibs file is better, but less files in debian/ is better. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: versioned shlibs file -- when and why
DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. This is a file to edit and some maintainer forget that. A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' Christian
Re: versioned shlibs file -- when and why
On Fri, Sep 07, 2001 at 12:09:39PM +0200, Christian Marillat wrote: DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: versioned shlibs file -- when and why
DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) Yes, but see libgal or gtkhtml. A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? In that case the shlibs file is better, but less files in debian/ is better. Christian
versioned shlibs file -- when and why
Hello, Suppose I have a package that produces a shared lib. Debian policy 9.1 says I need to create a shlibs file. No problem; dh_makeshlibs does exactly this. Now, the shlibs file can optionally have version info in it. Why would I want to put version info in there? One case that immediately comes to mind is if package version 1.1 produces libfoo, and version 1.2 produces libfoo *and* libbar. You'd need version info for libbar, yes? Other reasons? How is the -V option of dh_makeshlibs used? Using naked -V (i.e. not -V 1.2), you get a package that claims only the latest version is sufficient to satisfy the dependency on libfoo. What is the purpose of doing that? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, 2 Sep 2001, Steve M. Robbins wrote: Suppose I have a package that produces a shared lib. Debian policy 9.1 says I need to create a shlibs file. No problem; dh_makeshlibs does exactly this. Now, the shlibs file can optionally have version info in it. Why would I want to put version info in there? One case that immediately comes to mind is if package version 1.1 produces libfoo, and version 1.2 produces libfoo *and* libbar. You'd need version info for libbar, yes? Yes. Other reasons? Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. HTH, Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 03:44:32PM -0500, Colin Watson wrote: On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? Yes. More kindly phrased, it's the conservative option; it always ensures that other packages' shared library dependencies are at least as tight as they need to be, so that if the maintainer screws up then they won't break. The flip side is that packages might end up with dependencies that are too tight and so find it harder to be upgraded in testing: GNOME packages used to have this problem until the gnome-core maintainer started generating a more accurate shlibs file. Joey, perhaps dh_makeshlibs(1) could have a note in its man page saying something like this? I agree it would be nice if dh_makeshlibs had a note explaining what you did about the -V option. I also think it would be nice to have a note somewhere that the optional version field is useful for changes in the library ABI. Would the policy manual section on shlibs (either 9.1 or 9.4) be a suitable place for that? -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, 2 Sep 2001, Steve M. Robbins wrote: Suppose I have a package that produces a shared lib. Debian policy 9.1 says I need to create a shlibs file. No problem; dh_makeshlibs does exactly this. Now, the shlibs file can optionally have version info in it. Why would I want to put version info in there? One case that immediately comes to mind is if package version 1.1 produces libfoo, and version 1.2 produces libfoo *and* libbar. You'd need version info for libbar, yes? Yes. Other reasons? Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. HTH, Steve Langasek postmodern programmer
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? Yes. More kindly phrased, it's the conservative option; it always ensures that other packages' shared library dependencies are at least as tight as they need to be, so that if the maintainer screws up then they won't break. The flip side is that packages might end up with dependencies that are too tight and so find it harder to be upgraded in testing: GNOME packages used to have this problem until the gnome-core maintainer started generating a more accurate shlibs file. Joey, perhaps dh_makeshlibs(1) could have a note in its man page saying something like this? -- Colin Watson [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 03:44:32PM -0500, Colin Watson wrote: On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? Yes. More kindly phrased, it's the conservative option; it always ensures that other packages' shared library dependencies are at least as tight as they need to be, so that if the maintainer screws up then they won't break. The flip side is that packages might end up with dependencies that are too tight and so find it harder to be upgraded in testing: GNOME packages used to have this problem until the gnome-core maintainer started generating a more accurate shlibs file. Joey, perhaps dh_makeshlibs(1) could have a note in its man page saying something like this? I agree it would be nice if dh_makeshlibs had a note explaining what you did about the -V option. I also think it would be nice to have a note somewhere that the optional version field is useful for changes in the library ABI. Would the policy manual section on shlibs (either 9.1 or 9.4) be a suitable place for that? -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
