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

[Tzafrir Cohen]

On Tue, Jan 15, 2008 at 03:06:43PM -0800, Daniel Hazelbaker wrote:
> 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).

Good packaging is highly distribution-specific. For isntance, what
init.d scripts do you use?

> 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.

In order for Zaptel packages to be of any use, they would have to match
the exact kernel of the user.

With Debian, this means building for the 12 or so variants of each
kernel revision.

For anything outside Debian it gets worse: basically each new kernel
release you get a completely new kernel revision number, and hence need
to build extra set of drivers. For CentOS4 there are currently some 20
or so (just a guess of mine) different revisions. And that is before
counting SMP/non-SMP.

And when you're done with that, you'll notice other strange packaging
issues. For instance, have you noticed that Trixbox and Elastix have two
completely different naming convensions for the Zaptel modules packages?
It i quite impossible to make RPM packages that will run o both (unless
you resort to ugly tricks such as demi packages).

> 
> #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.

So get Asterisk into Fedora, and let them sort out the issues. 
Oh wait, this has been done already :-)

> 
> 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.

Could you please name those those kernel versions?

As a Fedora user, do you wish to package for the Fedora Kernel of the
Day?

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir