Re: package naming
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
Reply to: