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. :)
With this patch applied it is (still) not possible to link to
libcuneiform without jumping through extra hops. Worse still, it is not
possible to build a policy-compliant package linking to libcuneiform at
all; please consult Debian Policy 8.
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>
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.
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 ABI.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
