Neil McGovern <[EMAIL PROTECTED]> writes:
> How's this version? (attached)
> Neil
> --
> * hermanr feels like a hedgehog having sex...
> --- policy.sgml 2006-10-11 08:44:02.684306000 +0100
> +++ policy.sgml 2007-06-26 13:58:10.160026885 +0100
> @@ -2105,6 +2105,19 @@
> the file to the list in <file>debian/files</file>.</p>
> </sect>
> + <sect id="embeddedfiles">
> + <heading>Embedding code provided in other packages</heading>
> + <p>
> + Should the upstream source ship with a convenience copy of an external
> + library, and this library is already packaged in Debian, the Debian
> + package should not embed or include this code.
> + Instead, the package should be modified to reference the required
> + files in the library package provided by Debian, and a Depends and/or
> + Build-Depends relationship declared as required.
> + Optionally, the convenience copy should not be compiled in the
> + build-process.
> + </p>
> + </sect>
> </chapt>
I find this wording a little confusing in that I can't figure out whether
it implies the Debian maintainer should remove the embedded external
library from the upstream source tarball (which I don't think is what you
meant). The last line in particular seems to present as an alternative
the approach that I'd expect to be the most common.
Something like:
Some software packages include in their distribution convenience
copies of libraries from other software packages, generally so that
users compiling from source don't have to download multiple packages.
Debian packages should not make use of these convenience copies. If
the included library is already in the Debian archive, the Debian
packaging should ensure that the software is linked with the libraries
already in Debian and the convenience copy is not used. If the
included library is not already in Debian, it should be packaged
separately as a prerequisite.
Having multiple copies of the same code in Debian is inefficient,
often creates either static linking or shared library conflicts, and,
most importantly, increases the difficulty of handling security
vulnerabilities in the shared code.
perhaps?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
