Bug#392362: [PROPOSAL] Add should not embed code from other packages

[Chris Waters <xtifr@debian.org>]

On Sun, Oct 15, 2006 at 11:24:22AM +0100, Neil McGovern wrote:

> We want to avoid packages shipping their own versions of libraries,
> as then if a security problem or major bug is discovered in that
> library, we have lots of packages to update, and there's no garuntee
> we'll even know which packages it affects.

I don't know if it can always be avoided.  The perl-tk package, for
example, embeds its own versions of tcl and tk, but that's an upstream
choice.  Basically, they maintain their own fork.  On the one hand, if
a hole is found in tcl or tk, it might go unnoticed in perl-tk BUT on
the other hand, there's no guarantee that any other version of tcl or
tk will even work with perl-tk!  Can we force perl-tk upstream to
merge their fork?  I doubt it would be easy, but you're welcome to
try.  Should we re-fork perl-tk on our own?  That sounds like madness,
but you're welcome to try.  In either case, though, I think there's a
whole lot of required work before perl-tk could be brought in line
with this proposal.

Also, some libraries come with compile-time options, and a particular
package may need a version built with different options than the main
version of the library in Debian.  Ideally, we would provide an
alternate version of the library package, but it's not always that
easy.

I would go for strongly discouraging the practice, but I think that
flat-out forbidding it might be excessive at this point.  At the very
least, I think we should get some feedback from the people who are
engaging in this practice before passing any absolute bans.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku