Hi,
On Tue, 21 Aug 2007, JP Rosevear wrote:
> 1) The "simple" example at the end does not take into account where %doc
> files should go (AUTHORS, COPYING, README) etc.
>
> Suggestion is we say this goes into the lib<whatever><major> package
> number.
Not if it would generate a file conflict between README of libbla3 and
libbla4. The main theme for the whole policy is about packaging shared
libraries. It does also provide some best practices, but in general it
isn't concerned about where to package documentation. It can be either in
the main package (bla), a special docu package (bla-doc), in the -devel
package (libbla-devel), or somewhere else. If properly versioned it can
theoretically also be placed into the libbla3 packages (e.g. under
/usr/share/doc/libbla3/README), but for fear of people getting this wrong
(namely placing the files into .../libbla/) I would not mention that in
the policy. Currently the policy is quite simple: a libbla<number> rpm
contains exactly lib*.so.* files, nothing else. There are already
exceptions for this, and exception (3) would also apply to assorted
documentation files, so I don't see a pressing need to say something
explicit about them.
> Except I just ran into a case where the package had two different .so
> names
Split the lib package so that each provides just one library (preferred).
Otherwise both libs have to come together from upstream (same tarball for
instance, or same CVS module). Then that collection presumably has a name
and a version. You can use that as basename and number for the lib
package. I would not do that except if they are bound together very
tightly, and the version number is increased if one of the sonames is
touched.
> 2) No reference to .la files
>
> Do we finally want to kill those as a matter of policy? If so, should we
> write a macro to do it?
I read this about *.la files in the policy:
Package Contents
* Files needed to develop programs using shared libraries contained in
lib$NAME$NUM.rpm are packaged in a -devel package (see (4a) and (4b) for
cases that need to version this package). Those files include lib*.so,
lib*.la and all headers. ...
...
Best Practices
...
- Avoid packaging libtool config files (.la files). In general they are
not needed if you do not package a static library. If in doubt, ask.
So, avoid them if you can (and want to do the work involved). If you
don't, then package them into the -devel package. There are very peculiar
reasons why sometimes .la files have to be in the libbla3 packages, but
that's dealt with in exception (3).
> 3) Separation of soname number from library name
>
> We could always put the dash in for more consistency ie libz-1 instead
> of libz1 so when the library name ends in a number its libwhatever2-7
> and its easier for humans to parse (probably).
I find it easier without the dash actually. But that argument is all
about aesthetics, so not a very good one. A better one is perhaps that we
have already about 170 lib packages following the policy and most of them
are written without the dash (when they can).
> As well libssl is a horrible example to use because it does not follow
> proper .so naming, it always reflects the version number rather than
> incrementing based on ABI compatability
Have a better example? That example is supposed to show what needs to
happen if the soname doesn't contain only one number, but several ones
(i.e. to show the need for underscores). I fear all other examples doing
that have an equally horrifying "scheme" of dealing with so-versions :-)
Ciao,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
