On Sun, Aug 09, 2009 at 08:18:27PM +0200, Patrick Matth??i wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Wise schrieb: > > On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci > > (midget)<deb...@midworld.net> wrote: > >> Nick Leverton wrote: > >>> The upstream package contains private copies of libtalloc and pupnp, both > >>> of > >>> which are already included in Debian in their own right (libtalloc1 and > >>> libupnp3). Perhaps you could consider specifying --with-external-libupnp > >>> and --with-external-talloc in your ./configure. If there are any > >>> changes you need to libupnp3, I would be pleased to receive suggestions > >>> in the BTS. IANADD so I can't upload for you, sorry. > >> PS: Shall I remove from the original sources 'libupnp' and 'talloc' and > >> rename the package to be > >> DFSG, or it's OK to distribute upstream sources like that ? > > > > By far the best is to talk to upstream and get them to remove the > > embedded code copies along with any patches needed to build properly. > > ACK. > > > > > Personally I wouldn't bother stripping the embedded code copies from > > the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules > > just before the ./configure call so that there is no chance of the > > package being built against the embedded code copies though. > > Moving would be better, because with this way you are modifying the > tarball and then you will mostly have an error on building the package > twice.
AIUI, dpkg-source has no problem with files that are present in the .orig.tar.gz but are missing in the actual source directory - it just ignores the missing file and goes on. Isn't this the conventional way to deal with autotools-generated "configure", "Makefile", etc? So, IMHO, just removing them in the configure target should be fine. > I also do not see any need for it, if it realy builds against the system > wide libs. As Paul Wise said, the removing would be a good idea if the packager is not completely certain that the upstream build system will never, ever, under any circumstances, use the bundled source even if it is told to use the external libraries. Consider a build system that goes like, "Oh, okay, you told me to use the external library, but something changed, I can't quite locate the header file, or this definition is no longer available, or something just messed up... no matter, if I can't use the external library, I'll just use my own source, I *know* things will build just fine this way!". Honest, I've seen upstream sources that did that. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@space.bg r...@freebsd.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true.
pgp0tX7hZmew6.pgp
Description: PGP signature
