Re: readline and bfd libraries?

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

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.