[asterisk-dev] Easy packaging (Was unstable releases)

[Daniel Hazelbaker]

I have been following the "was" thread and wanted to spin-off a new  
thread for consideration.

What would people's thoughts be on spending some time and effort (new  
branch?) on getting Asterisk, Zaptel, Addons, etc. to be more easily  
packaged.  Wether that be changing source code, makefiles, or just  
providing "convenience" scripts.

For me, the hardest thing with even thinking about testing with trunk  
is that it is not always easy to rollback to a previous "version" if  
something is not working and you just can't get around it.  I am sure  
others have their own reasons for not wanting to run trunk and I admit  
I don't run it nearly as much as I wish I could, but the only way to  
do good testing is to make it a semi-live system.  For me that means  
the IT department phones are on our test (bleeding edge) server and  
everything else runs on the "stable" server.  But even with that, if I  
load up the latest svn and it keeps crashing, locking up, whatever and  
I just can't track down the problem I can't just not have my phones  
work.  So while I work on the specific problem I have found in a  
sandbox, I need my test server running something stable.

What I would like to see (and yes be willing to help with, but I don't  
want to go off half-cocked and do it myself and then have it only work  
for a small majority of people) is
1) An easier, overall, method for packagers to build up .rpms, .debs,  
etc.
2) A standard "stock" build that works for most people's needs  
(Asterisk is modular, how many people need special compile time  
settings?)
3) An automated "stock" packaging process that builds for as many  
platforms as we can accommodate without funky patching etc. scripts  
(hence #1).
3) A nightly, or more likely, semi-nightly automated packaging process  
from trunk and/or branches.

#1 I think we can do without too much effort, the biggest hurdle I  
myself have when building up RPMs is the dependancy issue(s).  It  
would be nice to find a way to build/install zaptel in such a way that  
asterisk can use it for building and same with addons (addons might  
already be okay with this).  I think the hardest part would be zaptel  
because of the kernel dependancies.

#2 again I think wouldn't be hard, just a matter of discussion.

#3 would be the hard one.  We would need either systems at digium to  
do this or volunteers that can run cron jobs nightly to look for new  
releases and automatically build, package and upload to a staging area  
for approval (make sure the entire set is there, no empty .rpms,  
etc.).  Because distributions change over time, sometimes with every  
release, their core library (libc, etc.), an rpm set for fedora 7 is  
not going to work with fedora 3.  At the moment, I have fedora 8 and  
fedora 6 on running machines and again would be happy to let them  
build automated packages.

If we can get #3 working then #4 is just a matter of debate.  How  
often?  Which branches (if any)?.  How long do we keep them around?

I think the hardest part in this whole list would be making Zaptel  
more easily packagable.  And personally, I would vote on just  
packaging it for the stock kernel in the release it is built for.  I  
rarely build custom kernels on anything but a "full" production  
server.  My test servers, because I often need to rebuild them ever  
few months, don't even bother doing a custom kernel for.

Something along these lines (and please comment on any aspect of this  
e-mail) I think would help to alleviate a number of the release  
problems.  As has been said, this is a major software package that has  
many aspects.  I do as much testing I can before going live, but I  
only use probably 5-8% of the functionality in Asterisk.  I think if  
we can make 1) the process of getting testable versions of trunk or  
even releases more convenient and 2) the ability to rollback incase  
something goes incredibly south quick and painless then we would a  
much better response from the community in testing trunk.

Regards and please comment!
Daniel Hazelbaker