David Engel writes ("Re: readline and bfd libraries?"):
> I'm beginning to think that all packages which provide shared
> libraries used by other packages need to be split into two or more
> packages. The first package contains only the shared libraries and
> minimal support files. The remaining packages should contain
> everything else (e.g. header files, static libraries, etc.).
I agree (well, there are probably some exceptions to this rule -
Electric Fence, perhaps, but perhaps those ought to provide static
libs instead).
> Also,
> the packages containing the shared libraries need to be designed such
> that multiple, major versions of them can coexist.
The way to do this is to encode the library major version into the
shared library package name.
I think we should have a convention for naming packages in these kinds
of relationships.
> As an example, here is how I'm currently planning to package Tcl in
> the new ELF version.
>
> tcl74 will contain tclsh7.4, libtcl7.4.so.1 and supporting run-time
> files and documentation. It will coexist with other shared library
> packages such as tcl75.
>
> tcl-dev will contain header files, static libraries and supporting
> documentation. Only one of these packages will be allowed at a time.
So the convention you're using here is
<package><library-major>
for the shared libraries and supporting run-time files and
<package>-dev
for the developer version.
> BTW, since I used Tcl for my example, I might as well ask this now.
> The command-level manual pages will go in the tcl74 package and the
> C-level manual pages will go in the tcl-dev package, but where should
> the script-level manual pages go? IMO, they should go with the
> interpreter in the tcl74 package, but making them coexist with tcl75,
> etc. would be impratical.
They might also be quite large, and wouldn't necessarily be needed by
all programs that are linked against libtcl.so. Perhaps a separate
package for the documentation ? tcl-doc sounds like the obvious name.
Does anyone have any better suggested conventions than
foo34 - the shared library libc.so.foo.34 and the supporting
runtime files
foo-dev - developers' files for foo
foo-doc - the documentation for foo (if there is a foo-dev
then that will contain documentation for its parts).
?
If this meets with general approval I'll put something about it in the
guidelines. (I suppose I'd have to change texidoc to texinfo-doc).
Ian.
