On 28.01.2011 0:55, Jakub Wilk wrote: > Hi Dmitry, > > * Dmitry Katsubo <dm...@mail.ru>, 2011-01-21, 13:36: >> I attach the trivial solution for the bug: the library header >> cuneiform.h is packaged as libcuneiform-dev.deb > > Apart from being trivial it is also wrong. :)
It is just a proposal, which of course might not be perfect. But I am happy we both understand the direction of improvements. > With this patch applied it is (still) not possible to link to > libcuneiform without jumping through extra hops. Sorry, I can't guess what you really mean here. Perhaps you need to give a concrete example about what does not work well. > Worse still, it is not possible to build a policy-compliant package > linking to libcuneiform at all; please consult Debian Policy 8. I've opened "Debian Policy Manual Chapter 8 - Shared libraries": http://www.debian.org/doc/debian-policy/ch-sharedlibs.html It has many subchapters. Perhaps you refer section 8.4 and the rule that there should be a symlink for shared library without a version number. I fully agree with this. I hope this is easy to fix (please do so). > All in all, package layouts should look like this: > > * cuneiform: > /usr/share/man/man1/cuneiform.1.gz > /usr/bin/cuneiform > > * libcuneiform<soversion>: > /usr/lib/libcuneiform.so.<soversion> > /usr/lib/cuneiform/libexc.so.<soversion> > /usr/lib/cuneiform/librsadd.so.<soversion> > /usr/lib/cuneiform/librlings.so.<soversion> > [... - and so on; it's better to keep these auxiliary libraries in a > private > directory, as other software is not supposed to link to them] > > * libcuneiform-dev: > /usr/include/cuneiform.h > /usr/lib/libcuneiform.so -> /usr/lib/libcuneiform.so.<soversion> Absolutely agreed. Looks very nice. > Apart from that, two things are worrying me: > > 1. A few types and constants defined in cuneiform.h have very generic > names ("enum Languages", "Bool", "LANG_ENGLISH" etc.). This is not > something acceptable in a public header file, and these names could > easily conflict with other names in user's code. Yes, this might be a problem, and I am already facing this problem with other libraries. If you can, please, raise this question in mainstream, in particular, adding a CPP namespace for all declared types. > 2. SONAME is currently "libcuneiform.so.1.0.0". Does it mean that it's > going to be "libcuneiform.so.<upstream-version>", i.e. changing with > every upstream release? That would mean that with every upstream release: > - Debian package would have to pass through the NEW queue. > - Packages linking to the shared library (if any) would have to be rebuilt. > This is not something I'd be happy about. SONAME should change if and > only if the new version actually breaks API. You're absolutely right here: the SO version number should be increased only when API changes. So do not change it with every upstream release (perhaps only the minor number). -- With best regards, Dmitry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
