asterisk dapper.2114_to_dapper.2234 diff

[Kilian Krause]

Mark,

Am Sonntag, den 06.08.2006, 22:20 +0100 schrieb Mark Purcell:
> On Sunday 06 August 2006 19:04, Jonas Smedegaard wrote:
> 
> > I have experienced some trouble and broken behaviour with installing
> 
> > and upgrading the current asterisk packages in sarge, etch and
> 
> > unstable, but have found the packaging somewhat a mess so have not
> yet
> 
> > filed bugreports about it. 
> 
> I think one of the issues is we are trying to maintain both
> asterisk-classic and asterisk-bristuff from the same source tree.
> 
To me that is still more a feature than a shortcoming. Yet I'm open to
discussion about how to more easily unify things. Like putting a large
'for feature in "" "bristuff";do...' or something, if that makes it less
of a headache for you.


> As a result debian/rules has become quite complex, which two runs
> through the build process one for each package. This means that
> maintenance is becoming a little complex, which means that mistakes
> are slipping through.

> Perhaps, we would be better off running the two packages from
> different upstream source trees, ie have one asterisk.xxx.orig.tar.gz
> and a different asterisk+bristuff.xxx.orig.tar.gz. Then the two aren't
> totally coupled and can progress at their own pace.
> 
Actually in my experience from the ekiga/gnomemeeting snapshots, it's a
*LARGE* benefit to only maintain stuff in one place. Just check how well
the sarge-backports branch of asterisk is cared about, which is already
in SVN, which is mostly updated, but nobody does commit to both trunk
and branches/sarge upon changing one thing. Thus, to me, I'd welcome to
ease things where others are confused by my style, yet I'd oppose
tearing apart sources where IMHO there's no good reason and benefit from
it.


> I don't personnaly have any bristuff hardware, so it is difficult to
> debug, but others are interested in its maintenance.

Yes, even though I find less time to dedicate to it, compared to what
I'd love to invest. Yet, so far it seems to still work nicely (at least
my i386 boxen is doing fine with bristuff+vzaphfc, the amd64 is having
problems accessing the kernel correctly from i386 userland). Problem
already forwarded to upstream of vzaphfc and will hopefully eventually
be solved.


> > I'd like to help cleaning up the packaging 
> 
> > and switching to using cdbs, if it is of any interest - so this
> thread
> 
> > (when cleared up the Debian<->Ubuntu prioritation) is highly
> 
> > interesting for me.
> 
> I'm very keen on cdbs, but others in pkg-voip mileage varies. The
> problem with the complex packaging we have for asterisk is that cdbs
> will struggle to keep up, with the current dual build enviroment. A
> two seperate single build packages would be suited to cdbs.

... one might want to call it a challenge for CDBS to show its abilities
and convince the ones in doubt among us. ;)

-- 
Best regards,
 Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20060807/eaec7abc/attachment.pgp