[Debconf6-data-commit] r571 - proceedings/27-Packaging-shared-libraries

[Alexander Schmehl]

Author: tolimar
Date: 2006-04-20 21:47:13 +0000 (Thu, 20 Apr 2006)
New Revision: 571

Modified:
   proceedings/27-Packaging-shared-libraries/paper.tex
Log:
fixed typos

Modified: proceedings/27-Packaging-shared-libraries/paper.tex
===================================================================
--- proceedings/27-Packaging-shared-libraries/paper.tex	2006-04-20 21:46:42 UTC (rev 570)
+++ proceedings/27-Packaging-shared-libraries/paper.tex	2006-04-20 21:47:13 UTC (rev 571)
@@ -129,7 +129,7 @@
 
 \subsection*{Providing a debugging version}
 
-If the library is known to causes crashes or is under development, the availability of debugging symbols is quite helpful. Fortunately, debhelper can do all of this automatically. After defining an empty \texttt{libfoo3-dbg} package, the magic command is:
+If the library is known to cause crashes or is under development, the availability of debugging symbols is quite helpful. Fortunately, debhelper can do all of this automatically. After defining an empty \texttt{libfoo3-dbg} package, the magic command is:
 \begin{verbatim}
         dh_strip --dbg-package=libfoo3-dbg
 \end{verbatim}
@@ -319,7 +319,7 @@
 
 To make things worse, a recent change in libtool introduced argument reordering at link time, which turns the \texttt{-\null-as-needed} option into a dummy one. This only happens when building libraries, not applications. A workaround was developed, as a patch for \texttt{ltmain.sh}, for the \texttt{libgnome} package where it is of large importance. It is currently waiting for a cleanup before being submitted as another Debian-specific libtool change\footnote{The upstream libtool developers have stated it may be fixed in the future, but not even in libtool 2.0.}.
 
-\section**{Conclusion}
+\section*{Conclusion}
 
 Apart from treating each update with care, there is no general rule for packaging shared libraries. There are many solutions and workarounds for known problems, but each of them adds complexity to the packaging and should be considered on a case-by-case basis. As the long list of problems shows, being release manager is not an easy task, and library package maintainers should do their best to keep the release team's task feasible.