On Mon, 29 Sep 2008 20:08:24 +0200 Leopold Palomo Avellaneda <leo@alaxarxa.net> wrote: > > > Yes, you are right. But I prefer the Debian library packaging guide, it's > > > more clear in this aspect. However I guess than the author uses the > > > version number as the SONAME number and don't know how to change it. > > > > Eh? If the library version is 3.5.6 and the SONAME is 0.0.0, then that > > is good and correct. > > Yes ... but I guess that upstream have broken the ABI in the several versions > of the library. Maybe, but that was then. > > What matters is now - educating upstream to tweak the libtool > > versioning *separately* from the version string when the ABI next > > changes. > > Uff. Who am I to try to educate to upstream? :-) I can try to send an email > about it, but ... You are the Debian Maintainer. You have a responsibility to work with upstream in a cooperative, effective and friendly manner. You need to talk with upstream, persuade them, advise them, recommend changes, listen to them, understand their perspective and make a relationship with them. > > Take a look at my own library (upstream and Debian) - QOF. > > you use cdbs ... I don't like it, but it's just my opinion.... What we are discussing here is not related to the Debian packaging, CDBS is not an issue here. Nothing you do with these SONAME issues needs to have anything to do with CDBS. SONAME work happens upstream, in debian/control and only partially in debian/rules. > > That is how the SONAME should be set. > > That's what I wanted to know!!!! But I will not patch upstream. No, you should not patch upstream to do things like that. SONAMEs are an upstream decision. You need a relationship with upstream where you listen to them and they listen to you. > > and ensure that they update > > the LDFLAGS in the relevant Makefile.am to denote when the next > > ABI/SONAME change happens. > > Ok, I will prepare a mail with all this information to "educate" upstream. Build a relationship first - get on their side and work with them - don't just bash them. > [...] > > > > Packaging libraries is a complex task - do NOT do it unless you are > > confident that you can work with upstream to get it right. > > I know that is a complex task, but it's a nice task because you learn a lot of > packaging. And that's your problem - it isn't mostly about packaging, it is about working with upstream to coordinate transitions and ABI changes. > > If you don't understand the GNU libtool manual, then forget this > > package right now. Please don't add another broken library to Debian. > > It's not a question of understanding, I have just said that I prefer how is > explained in the Debian Library Packaging Guide. And, I don't want to add any > broken library, of course. It *is* about understanding - you must understand the libtool manual so that you can apply the lessons from it to the problems as upstream present them. The Debian Library Packaging Guide might not cut much ice with upstream, the libtool manual commands more respect - once you help them understand it within the context of their library and development patterns. Get to know upstream and work out their workflow then apply your knowledge so that you can offer a solution that they can understand and which they can see has been worked into what they normally do. > > Generally, maintainers should package several "ordinary" binary > > packages BEFORE even considering a library. > > Yes, this is the first thing that I thought. But, my main problem is that the > software that I would like to package (because I like or I use or I think > intersting, etc), in general _ALL_ are libraries, so what's supposed that > should I to do? Find some other orphaned binary packages to work on? > Package a software that I don't like, or I don't use? Use wnpp-alert or rc-alert and find something that you do use. > I'm not be able to maintain a package that I don't use/like. I prefer to make > the afford to package something to me important. Of course, that is essential to all of us. However, you don't just use libraries - you have to use some binaries, at least some of them could be useful to package, even if you don't try to get them sponsored. > [...] > > > > If you can locate them during the build and they could be useful to > > others (without being compiled), then put them > > in /usr/share/doc/$package/examples/ > > They are build with autotools, so they are not very useful without a plain > makefile. But I can build one. The source code itself is probably useful - hence why I suggested /usr/share/doc/*/examples because then users don't expect to be able to compile them without some effort. It's a case of documentation-by-RTSL -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpmO_SgCDev5.pgp
Description: PGP signature