[asterisk-users] New CentOS 5 repo: dahdi, asterisk, freepbx RPMs

[D Tucny]

2009/3/28 Jason Parker <jparker at digium.com>

> D Tucny wrote:
> > 2009/3/26 John Morris <asterisk at zultron.com <mailto:asterisk at zultron.com
> >>
> >
> >     Hi, Axel.
> >
> >     Axel Thimm wrote:
> >      > How about merging in your changes/improvements/new packages with
> >      > ATrpms (and automatically later into rpmrepo.org
> >     <http://rpmrepo.org>)? That way we won't
> >      > have further fragmentation and a larger user base to test bits
> (which
> >      > will be distributed in stable, testing etc repos).
> >
> >     Of course I'd love to contribute my changes to ATrpms.  Some of the
> >     small changes I made, such as adding OSLEC to the DAHDI RPMs, might
> be
> >     nice for ATrpms users.  I'll whip up some patches against the ATrpms
> >     sources.
> >
> >     My problem with ATrpms, though, is that the RPMs make use of many
> custom
> >     macros that make them unbuildable outside the ATrpms environment.  I
> >     understand that might be necessary for RPMs like DAHDI that build
> kernel
> >     modules for several versions of several distros, where vanilla
> specfile
> >     code would get hairy.  (I think we had this discussion a couple of
> years
> >     ago on the ATrpms ML.)  Since I don't have to worry about multiple
> >     versions of multiple distros in my environment, I prefer to use
> vanilla
> >     specfile that will rebuild on anyone's CentOS 5 system.
> >
> >
> > Alternatively, there's also the RPMS at
> > http://packages.asterisk.org/centos/ which seem to have a nice spread of
> > options available, including 1.4/1.6 packages, are pretty nicely
> > modularised and seem to be kept pretty fresh... They do however seem to
> > have some issues that your RPMS (and Axel's) don't (e.g. why wouldn't an
> > init file be included? and where's the changelog?)... Perhaps it would
> > be useful to help the digium packager build some better packages... That
> > would also help with reducing fragmentation, if there were decent
> > quality 'official' packages available then it would save the time and
> > effort Axel and the rpmrepo.org <http://rpmrepo.org> folks too as they
> > could in theory base any extras on those packages rather than needing to
> > maintain the entire set...
> >
> > d
> >
>
> As the author of the RPMs at http://packages.asterisk.org/ (as well as
> http://packages.digium.com/), and the maintainer of the repositories, I
> wanted
> to respond to this.
>
> I would love it if some of this were to happen.  I am very familiar with
> Axel
> and ATrpms - he has proven countless times that he knows what he's doing
> when it
> comes to this sort of thing.  Getting help/advice from somebody like him
> would
> be extremely beneficial.  As far as basing the ATrpms (or others) packages
> on
> the AsteriskNOW packages, if that is something that Axel (or others) wanted
> to
> do, I would be more than willing to help with whatever is needed.  On a
> somewhat
> related, and very interesting note - I found out yesterday that the latest
> trixbox beta is using these RPMs (without even needing to rebuild them, in
> some
> cases).  Hopefully that means I'm doing something right.
>
> D, the two issues you brought up are valid.  For the Asterisk RPMs, I
> honestly
> don't know why there isn't an init script - I actually thought there was
> one.
> FreePBX is what starts Asterisk in AsteriskNOW, so it was easily
> overlooked.  It
> will be there in future builds.


Cool... I tried the 1.6 packages out a couple of days ago, not using
FreePBX, the biggest issue I've found so far was the lack of init scripts,
both in the asterisk packages and the dahdi... I'll have a look at patching
the spec's to make them more usable without freepbx and feed back to you...


> As far as the changelog, it was one of those
> things that I intentionally left out for a while, and I kept meaning to "do
> it
> later".  Really, it's because I'm not sure what should go into an RPM
> changelog
> (I'd love to hear from anybody that has any insight into that).
>

What would typically go in an RPM changelog (as with most changelogs) is a
note associated with each revision...

e.g. for the asterisk16 RPM you may have something like this (which I
knocked up from looking at the specs for each release) that makes it simple
to see why there is a new revision without having to dig through the
SRPMs...

%changelog

* Sat Mar 21 2009 Jason Parker <jparker at digium.com> - 1.6.0.6-2
- specify asterisk:asterisk ownership and specific permissions of
directories and files that should be writable at runtime

* Tue Feb 24 2009 Jason Parker <jparker at digium.com> - 1.6.0.6-1
- Update to 1.6.0.6
- add astapi variable and add provides with that variable for each child
package
- include func_audiohookinherit.so, aelparse and conf2ael
- change useradd to use '-r' to create a system account with UID below
UID_MIN and produce no output

* Wed Feb 11 2009 Jason Parker <jparker at digium.com> - 1.6.0.5-1
- Update to 1.6.0.5
- add distname and distver variables to allow logic for building on other
dists
- add logic to modify buildreqs and reqs if building for suse/sles
- make newt buildreq optional (without_newt)
- include odbcstorage and imapstorage in splitopts patch

* Wed Nov 12 2008 Jason Parker <jparker at digium.com> - 1.6.0.1-3
- Change from linking to copying odbcstorage and imapstorage voicemail
modules
- Change config option to noreplace to avoid overwriting modified configs

* Mon Oct 13 2008 Jason Parker <jparker at digium.com> - 1.6.0.1-2
- Added resample subpackage

* Thu Oct 9 2008 Jason Parker <jparker at digium.com> - 1.6.0.1-1
- Initial 1.6 build.


>
> As always, if anybody has any ideas, suggestions, criticism, or any other
> type
> of feedback, I'd be happy to hear from you.
>

I hope this helps... I'll drop more feedback to you directly at some point
and hopefully John, Axel, Tzafrir and others will do the same...

d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090329/298b3234/attachment.htm