[asterisk-dev] Easy packaging (Was unstable releases)
daniel at highdesertchurch.com
Wed Jan 16 11:39:38 CST 2008
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
>> 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
> the exact kernel of the user.
> With Debian, this means building for the 12 or so variants of each
> kernel revision.
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
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
> 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
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?
> 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
More information about the asterisk-dev