RFS: knoda - a database frontend for KDE based on the hk_classes library.

[Mike Schacht <mschacht@alumni.washington.edu>]

Hello, 

Here we go again... Looking for a sponser for knoda. 
Source and binaries are at:
	www.midstatesd.net/~mschacht/debian

As described in the .deb:

 knoda is a database frontend for KDE. It is based on hk_classes and is
 released under the GNU General Public License (GPL).  Knoda allows you
 to:
      * define and delete databases; create, alter and delete tables and
      * indices; add, change and delete data in tables; define, execute
      * and store sql queries; import and export CSV data; define and
      * use forms; and define and print reports
 Its driver concept allows a uniform connection to
 different database servers.


This is actually a bit more complicated than I have let on. Knoda
uses hk_classes, which includes the usual runtime and development
libraries in addition to a runtime driver plugin. hk_classes is
distributed separately by the upstream author. Knoda uses another library
called hk_kdeclasses that is distributed in the same source package as
knoda itself. 

So I really need a sponsor for the app, the two libraries and the
plugin. I don't know if it is best to do them all at once with the same
sponsor or to start with just the hk_classes libraries.

Meanwhile I had some questions about the libraries. It may turn out that
I am in well over my head, but I read the whole of the library packaging
manual and, as this LPM suggested, the libtool manual (really) so I
think have it in pretty good shape. 

I am, however, stuck on a bit of pedantry regarding the developer
package names. Policy, 11.3, states that it is reasonable to omit the
SONAME version number from the developer package name, though requires
it for the runtime package, but the packaging guide:
www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN68
insists that this is 'very discouraged'. I am inclined to rely more on
the packaging guide as it is the only one of the two with a strong
opinion either way, but leaving the version number out seems like it
might be less work for me in the end.


Less trivially, this app, knoda, is the only one I know of that uses
this library, hk_classes. As a result I am a bit queasy about polluting
/usr/lib in particular, and the package collection in general, with a
shared library that is used only by one app. I would have felt a little
better hiding the files away in /usr/lib/hk_classes or similar, but I
couldn't without offending the rpath policy. 

This same question came up a while back on the list, and in the course
of this discussion someone (Bob Proulx) suggested:
lists.debian.org/debian-mentors/2002/debian-mentors-200209/msg00233.html
just building the static library and link the app to that.

There was no followup to that idea so I can't tell if it is generally
regarded as the appropriate thing to do. I seem to be able to manage it
fairly easily with a strategically placed --enable-shared=no. But then
what kind of additional packages should I build. Do I just make a
libhk-classes-dev availble so that knoda can be rebuilt and forget about
the runtime shared lib packages as they are not required to run the app?

Advice appreciated.

Thanks,

Mike Schacht
mschacht@alumni.washington.edu