Bug#392362: [PROPOSAL] Add should not embed code from other packages
Colin Watson <cjwatson@debian.org> writes:
> This has the unfortunate property of excluding Gnulib, which is a
> library of code explicitly designed by the GNU build system folks to
> live alongside the Autotools and be copied into packages to provide
> replacements for missing functions. Perhaps something like this would
> work?
>
> Debian packages should not make use of these convenience copies unless
> the intent of the other package is explicitly to be copied in this
> way<footnote>For example, parts of the GNU Build System work like
> this.</footnote>, and the other package provides a straightforward
> mechanism for keeping the copy up to date.
I'm not sure that the last bit really applies to Gnulib, and I'm not sure
it's easily measured. I'm inclined to leave it off and just go with this:
--- orig/policy.sgml
+++ mod/policy.sgml
@@ -2077,6 +2077,34 @@
the file to the list in <file>debian/files</file>.</p>
</sect>
+ <sect id="embeddedfiles">
+ <heading>Convenience copies of code</heading>
+
+ <p>
+ Some software packages include in their distribution convenience
+ copies of code 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 unless the included package is explicitly
+ intended to be used in this way.<footnote>
+ For example, parts of the GNU build system work like this.
+ </footnote>
+ If the included code is already in the Debian archive in the
+ form of a library, the Debian packaging should ensure that
+ binary packages reference the libraries already in Debian and
+ the convenience copy is not used. If the included code is not
+ already in Debian, it should be packaged separately as a
+ prerequisite if possible.
+ <footnote>
+ 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
+ duplicated code.
+ </footnote>
+ </p>
+ </sect>
+
</chapt>
After all, simply satisfying this requirement doesn't give one a free pass
through the security team evaluation, and they can always reject packages
for other reasons.
Unless there are any objections, I'll commit this for the next version,
since I think we've pretty much reached consensus on it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: