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

[Daniel Hazelbaker]

On Jan 16, 2008, at 12:46 AM, Tzafrir Cohen wrote:

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

As I said, it would take some work.  But this, I feel, should be done  
regardless. Hence why I put some patches on mantis for adding the  
ability to build RPMs from Asterisk, Zaptel and Addons, though I admit  
they have fallen by the wayside over the holidays and I need to get  
back to them and get them updated.  I am not saying we need to cover  
every single distribution, but if we get a few of the major players  
covered, and setup in such a way that it is generally package  
friendly, then it would not be too difficult for people to submit  
patches to add functionality to other distributions.

>> #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.
> [snip]

Hence, the automated build scripts.  The scripts check various  
dependancies for changes, like Zaptel version, kernel version, etc.,  
when changes are detected then the new packages are built.  And just  
like (since I am familiar with it) Fedora does, when they update the  
kernel they update all kernel-dependent packages, like certain X11  
drivers.  You cannot get the new X11 driver without updating your  
kernel too.

Yes there would be a number of variants to "support", but at the very  
least I think this step should be taken as at the very least it would  
be easier to people to work with version changes as they could run a  
script on their own system to build a (set of) packages for their own  
configuration.  But I know this type of thing is doable as other  
groups do the same.  There are many yum repositories that carry RPM  
packages for a number of different releases of Fedora and other  
distributions.

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

I haven't noticed asterisk in Fedora, but if it is that is great.   
But, and I am sure you were not intending this, we cannot expect them  
to keep up with the most recent versions. Like most other software  
they will pick a release that they deem stable and use it until they  
feel like another release is worth repackaging.

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

Nope, just the one in the yum repository.  Fedora 8 kernel was last  
updated Dec 19, and has only 3 varients (stock, PAE whatever that is,  
and xen). Fedora 7 kernel Jan 2, same 3.

I am not saying that we can cover everything.  Personally, at the  
moment, I can cover Fedora 8 stock and Fedora 6 stock.  What I am  
saying is I think we should make it easy for the community to cover as  
much as possible.  If somebody uses Fedora Core 2 (dear God...) still  
and wants to run the packaging script, great.  I think the goal should  
be to get as many people using trunk and other testing branches as  
possible instead of sitting around waiting for a new release to come  
out.  I have seen many people saying this needs to happen, but nobody  
giving ideas on how to get more people to use trunk.  I think #1 at  
least would be a step towards accomplishing this.  If nobody else  
thinks this is a good idea, great, what other ideas might we look at  
for getting more interest in trunk?

Daniel

>               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