Bug#446915: Allow user to build opal with iLBC codec from upstream source

[Kilian Krause]

Alain,

On Wed, Oct 17, 2007 at 01:36:41AM +0200, Alain Kalker wrote:
> Kilian,
> 
> On Tue, 2007-10-16 at 23:58 +0200, Kilian Krause wrote:
> > you already are able to achive this by plain using the Debian diff.gz file
> > with the upstream source tarball and then remove the line "remove_ilbc"
> > from debian/patches/00list before running the build.
> 
> Thanks, but I think (haven't tried yet) the build will then fail on the
> check-ilbc target, because that specifically checks for the presence of
> the src/codec/iLBC directory. Ofcourse removing check-ilbc from the
> clean target would fix that, but this adds to the number of steps that
> have to be taken after upgrades.

right. That check-ilbc target is in fact the second step to take. But
that's as good as it gets.


> To make it easier to do this, I was wondering if you could introduce a
> make variable like BUILD_DFSG (defaulting to "yes") to control whether
> or not DFSG-free packages will be built. This could then be overridden
> during build, or perhaps using a value for DEB_BUILD_OPTIONS and a test.
> Users can then use the get-orig-source target to automate fetching the
> upstream source, editing the patch list for non-DFSG builds or deleting
> the iLBC directory for DFSG builds, then do a normal package build. This
> might even make the check-ilbc target redundant.

Well, no. The get-orig-source reads from debian/changelog and it could
be made to autosense the ~dfsg in the version there like pwlib does..
The build flag _could_ circumvent the check-ilbc step and could run a
dpatch unpatch remove_ilbc after the patch target (i.e. first in
autotools), but this starts becoming pretty hacky. Especially compared
to this is 3 manual steps. Sure it's feasible, but OTOH is there such a
large user base that want to do this on their own? Agreed I'm willing to
rework the get-orig-source target for the next upload to cope with this.
But that's about as good as I see a need for it.


> Also, packages built from full upstream source will still have the
> suffix "-dfsg" in their version strings, which could confuse users,
> especially during upgrades. This is a problem with all "-dfsg" packages
> at the moment, and I am considering bringing up this topic on the
> developers list.

Actually I don't see a problem here. 

-- 
Best regards,
Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20071017/76f9ffa6/attachment.pgp