Bug#506251: [RFS] amule-adunanza for Debian

[Moritz Muehlenhoff <jmm@inutil.org>]

On Fri, Jan 02, 2009 at 02:22:29PM +0100, Adeodato Simó wrote:
> * Luca Falavigna [Wed, 17 Dec 2008 00:22:47 +0100]:
> 
> > Hello Adeodato,
> 
> Hello, Luca, sorry for the late reply.
> 
> > You're aMule Debian maintainer, so your opinion is important.
> 
> > Fastweb is an important italian ISP which implements a kind of network
> > based on a NAT technology: every customer is part of Fastweb huge WAN
> > and Internet contents are proxied. amule-adunanza project [1] is meant
> > to help Fastweb users to use Kademlia network allowing clients to be
> > reached inside Fastweb's NAT, traditional aMule is not able to do so.
> 
> > Adunanza is a "merge" of aMule, it uses the same aMule code,
> > implementing Adunanza changes on top of it, new stable versions happen
> > when new aMule version come out.
> 
> > I packaged a first version of amule-adunanza [2] and opened a ITP for it
> > [3], it is mainly based on existing aMule package in Debian, since code
> > and packaging is almost the same, the only major change is lack of
> > amuleweb, it hasn't been tested by Adunanza developers and they
> > suggested to not ship it for now.
> 
> > Just for the records, it has been made available in Ubuntu recently [4].
> 
> The only thing that comes to mind is that we don't like code duplication
> in Debian much. That is, we like code to live in exactly one source
> package. For this to work here, amule would have to provide an amule-src
> package, and get amule-adunanza to build-depend on it, applying its diff
> on top of it. (This way, if a security problem happens in amule, a
> simple automatic binNMU is enough to get it fixed in amule-adunanza.)
> 
> I'm not sure, however, if it's worth the effort. After all we are
> talking only of two packages (and foreseeably none more), and I don't
> think there have been any security uploads of amule in the past.
> 
> Another option would be to include the adunanza diff in the amule
> package itself, but I'm not very keen on that either.
> 
> Let's CC the security team, to see if they insist that we duplicate this
> codebase, or can live with it.

The best solution would be to merge the necessary changes into amule
proper. Since there'll be 18 months of time until Squeeze release there
should be plenty of time to do that.

The second best solution would be to build another binary package from
the amule source package, which is applying the adunanza patch during
build time.

Or we could build a separate source package and exclude amule-adunanza
from security support.

Cheers,
        Moritz