On Mon, Feb 12, 2001 at 04:21:00PM -0800, Mike Markley wrote: > IMO the best name is the one that does the best job of expressing what it's > called without being so generic as to cause potential name conflict. I'd > personally go with libmetakit, with -dev, -tcl, -python if you split it up. > In general the version number isn't in the package name unless there's some > pressing need to be able to install multiple versions at the same time, so > hopefully libmetakit4 or 40 won't be necessary. If the library is under development, I think it would be better to include the version number in the package name. It happens sooner than you think that a new (uncompatible) version comes out, some people want the old, some the new, then you need to rename one or both packages and you are in trouble. When I packaged my first lib, I asked the same and was told not to put the version number into the name. I found it a bit of a mess to change it later on, especially since I could not force packages which depend on "my" lib to use the new one, lots of bug reports were coming in, since the other packages did not work as expected anymore. to use the new lib, the source of those packages had to be changed. It proved to be better to have seperate libraries with other packages explicitely requesting which one they need. YMMV.
I would recommend not to put "lib" into the package name. If you prepare the package with dh_make, call it metakit40, and say its a lib, the control file will have "lib" added before the individual packages. Then the source package will be called metakit40 (which might be closer to the upstream name?), but the libraries will be libmetakit40-*. I think its nicer that way (although many source packages also carry "lib" in their name), but its just a matter of taste. Christian