[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: djmount



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)<debian@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	roam@ringlet.net    roam@space.bg    roam@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.

Attachment: pgpwROpaVhb83.pgp
Description: PGP signature


Reply to: