On Mon, Jul 16, 2007 at 11:57:18PM +0200, Kurt Roeckx wrote: > On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote: > > Steve Langasek <[EMAIL PROTECTED]> writes: > > > > > Perhaps "common code" or "duplicated code" instead of "shared code", to > > > avoid ambiguity wrt shared libraries? > > > > How about "duplicated code"? New patch:
I would like to stress the point that is is better to get a limited version of this in the policy and then expand it with hindsight than to try to cover all cases from the start. > I have 2 comments about this: > - It was suggested that this shouldn't only cover libraries. This > version still only takes about libraries. When I wrote this, I meant library in the general sense, not in the "shared library" sense to cover perl, python, php, ruby, haskell modules etc. A library being a piece of code set up to be used in a larger programm rather than on its own. I find the wording "convenience copy of library from other software packages" much more telling than "convenience copy of code from other software packages" that could be misinterpreted. For example, a lot of packages include a convenience copy of scripts part of automake (install-sh, depcomp, etc.). The sentence "Debian packages should not make use of these convenience copies." seems to imply that they should not be used. > - 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. This is a non-Debian-specific best practice, so probably does not belong in policy. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
