Bug#392362: [PROPOSAL] Add should not embed code from other packages
- To: Kurt Roeckx <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Bug#392362: [PROPOSAL] Add should not embed code from other packages
- From: Russ Allbery <email@example.com>
- Date: Mon, 06 Aug 2007 00:08:04 -0700
- Message-id: <firstname.lastname@example.org>
- Reply-to: Russ Allbery <email@example.com>, firstname.lastname@example.org
- In-reply-to: <20070716215718.GA29591@roeckx.be> (Kurt Roeckx's message of "Mon, 16 Jul 2007 23:57:18 +0200")
- References: <email@example.com> <20070618172743.GB3687@yellowpig> <20070625130221.GD23964@mx0.halon.org.uk> <20070625153353.GQ3320@yellowpig> <20070626125958.GM23964@mx0.halon.org.uk> <firstname.lastname@example.org> <20070626223046.GO23964@mx0.halon.org.uk> <email@example.com> <20070704090125.GA26366@dario.dodds.net> <firstname.lastname@example.org> <20070716215718.GA29591@roeckx.be>
Kurt Roeckx <email@example.com> writes:
> On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote:
>> Steve Langasek <firstname.lastname@example.org> writes:
>>> Perhaps "common code" or "duplicated code" instead of "shared code", to
>>> avoid ambiguity wrt shared libraries?
>> How about "duplicated code"? New patch:
> I have 2 comments about this:
> - It was suggested that this shouldn't only cover libraries. This
> version still only takes about libraries.
A valid point. See a proposed new wording patch below which uses "code"
instead of libraries and tries to be more general. Does this look good to
you? And do the other people who reviewed the previous wording proposals
have any objections?
> - Some packages contain a forked version of a library. Policy should
> say to try and merge them in the Debian package. This might
> not work for all packages since the changes aren't compatible, in
> which case I see 2 options:
> - Keep it internal and link staticly
> - Make a seperate source package of it.
> It would be nice if policy suggested one of those approaches. But I'm
> not really sure this belongs in policy.
I can see wanting to do one of those things in some cases and another in
other cases. I think the wording below encourages the separate source
package where possible, but allows for the internal use and static linkage
where it isn't, which from a Policy perspective is probably the best that
we can do.
@@ -2077,6 +2077,30 @@
the file to the list in <file>debian/files</file>.</p>
+ <sect id="embeddedfiles">
+ <heading>Convenience copies of code</heading>
+ 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. 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.
+ 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.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>