Re: How to deal with "assets" packages shadowing real upstream
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote:
> Oh - I just discovered that this _is_ covered by Policy §4.13 already.
Reading that again, I see that it says code copies are acceptable if the code
is meant to be used that way (with GNU autotools as an example in the
footnote). For convenience, I quoted the whole thing below.
I think consensus has changed on this issue: this practically means "run
configure as shipped by upstream". As far as I know, we now recommend
regenerating everything from source (configure.ac, Makefile.am). Should this
be changed in policy?
Thanks,
Bas
4.13 Convenience copies of code
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.[29] 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. [30]
[29] For example, parts of the GNU build system work like this.
[30] 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJW3xiUAAoJEJzRfVgHwHE6WOgP/0D9QUq1YIA35swoccr+NHTF
NR3/JPc2CHhml0g8R90QPKRFnn+bBOtVC+660R9y5dCWinF1+dgSi1PRXwgVN/yi
iMAJyWlOKhu0p5otlWhWL5ikEBQNlNwL4p2+o/mJwTlkmCzXqjiv5oTbcS5ZMsWE
4+GyQNJS77UrIQ5pznBIf5pWcnVElECXp/Ayd1/dW1zr+nftHR1f/4feyd/z2yLv
F+Qyo1RQd2ig8WM++fvXbvjfjMHj56OUNGkZb+9aiKXVXgsaKjVS98jKOZ8140iM
JLjqZEZn3Uw73NozgoAN42OKQQa46G/3XjSsSiiXN/rnRl2DdS8K/Z1tG+QX0z/P
IB8Rs+/FEqg22Az9hmtJ+QhPrgEovv+CMQu0ZTy8Va6ah0n7cAE21fPKMuL/1VW1
izx5kFEQLpiU70po/xmlKpMXPZ4HnwuSZWL8wp2t5ofI2knZC5x52pkJ2kKNxvy1
Agv4S9RviKzf9F4VkvnjSEumX5EQs6vJ6QwvgYGVGVCgwcvfRVa1PotcULDktesb
oik7ZH8E0YQPh3mYYttmnjswuPRZ9YQUpS55bTUv9hi2gnR3+7eBdCL18cOQgFx2
Ta6R4/gPO67sSOTGoIptIPELcquNPpZ2XNSqXmxrDQMjS3/82N2yF7FASZ6Hhe+G
vqNNj9w1JIZ1r/157ROZ
=Ynrt
-----END PGP SIGNATURE-----
Reply to: