Re: [luabind] Naming library with proper SONAME
On Tue, Mar 10, 2009 at 06:30:19PM -0400, Roberto C. Sánchez wrote: [My apologies in advance for the cross-posting.] On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote: Roberto C. Sánchez wrote: So, I've been trying to build the Debian package with the latest from the 0.8 branch on github. It seems like the SONAME thing is not completely resolved. I am seeing this after building: robe...@miami:~/src/luabind-upstream$ objdump -p ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME SONAME libluabindd.so.0.8.0 Yes, that's the expected result, isn't it? The reasoning was that it's too difficult to have ABI-compatibility, so we just use the complete version number as the SONAME. bjam install will create the unversioned symlink. I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? I have done some further digging and found a blog post [0] that explains the issues with templated C++ code and ABI. What it boils down to is that if templates are used in a library, it really cannot have an ABI. I also found a bug report [1] against gecode that was closed with a similar explanation. The solution implemented by the libgecode maintainer in Debian was to increment the SONAME for each release. That said, I think that the best solution is to have a different SONAME for each release, based on the use of template code. Since it is currently being set as the library's release version, that is probably the way to go. Additionally, I guess it is important for me (as the person packaging the .deb) to know what the planned release frequency is going to be. The reason is that each SONAME change will result in a new package being created and in a library transition (should libluabind gain any reverse dependencies). Each time that happens, the package will have to pass NEW processing. Regards, -Roberto [0] http://julipedia.blogspot.com/2005/10/c-templates-and-abi.html [1] http://www.gecode.org/bugzilla/show_bug.cgi?id=24 -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [luabind] Naming library with proper SONAME
* Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]: I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [luabind] Naming library with proper SONAME
On Thu, Mar 12, 2009 at 10:18:59PM +0100, Adeodato Simó wrote: * Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]: I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [luabind] Naming library with proper SONAME
* Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]: It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Yes, but I asked about an *estimation* of how many there *will* be. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [luabind] Naming library with proper SONAME
On Thu, Mar 12, 2009 at 10:39:37PM +0100, Adeodato Simó wrote: * Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]: It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Yes, but I asked about an *estimation* of how many there *will* be. Good question. I do not know, but I would be surprised if it were more than a handful (10 at most). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [luabind] Naming library with proper SONAME
Roberto C. Sánchez robe...@connexer.com writes: [My apologies in advance for the cross-posting.] On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote: Roberto C. Sánchez wrote: So, I've been trying to build the Debian package with the latest from the 0.8 branch on github. It seems like the SONAME thing is not completely resolved. I am seeing this after building: robe...@miami:~/src/luabind-upstream$ objdump -p ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME SONAME libluabindd.so.0.8.0 Yes, that's the expected result, isn't it? The reasoning was that it's too difficult to have ABI-compatibility, so we just use the complete version number as the SONAME. bjam install will create the unversioned symlink. I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? I've looked in the Debian library packaging guide and it does not say one way or the other. I'd appreciate any insights and/or comments. Regards, -Roberto The ABI needs to be compatible across all versions with the same SONAME. If that means every upstream release gets a new SONAME than I curse upstream for breaking their ABI all the time but the SONAME would still be right. This should not really be a showstopper but maintaining this won't be too easy. Every new upstream release will need a binary package name change, NEW procesing and a library transition. You better hope that the API doesn't change as often so binNMUs can be done. One would hope that at some point there will be a libluabindd 1.0.0 which would then have a more stable ABI. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
