<div class="gmail_quote">2009/3/26 John Morris <span dir="ltr"><<a href="mailto:asterisk@zultron.com">asterisk@zultron.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, Axel.<br>
<div class="im"><br>
Axel Thimm wrote:<br>
> How about merging in your changes/improvements/new packages with<br>
> ATrpms (and automatically later into <a href="http://rpmrepo.org" target="_blank">rpmrepo.org</a>)? That way we won't<br>
> have further fragmentation and a larger user base to test bits (which<br>
> will be distributed in stable, testing etc repos).<br>
<br>
</div>Of course I'd love to contribute my changes to ATrpms. Some of the<br>
small changes I made, such as adding OSLEC to the DAHDI RPMs, might be<br>
nice for ATrpms users. I'll whip up some patches against the ATrpms<br>
sources.<br>
<br>
My problem with ATrpms, though, is that the RPMs make use of many custom<br>
macros that make them unbuildable outside the ATrpms environment. I<br>
understand that might be necessary for RPMs like DAHDI that build kernel<br>
modules for several versions of several distros, where vanilla specfile<br>
code would get hairy. (I think we had this discussion a couple of years<br>
ago on the ATrpms ML.) Since I don't have to worry about multiple<br>
versions of multiple distros in my environment, I prefer to use vanilla<br>
specfile that will rebuild on anyone's CentOS 5 system.<br>
<font color="#888888"><br>
</font></blockquote><div><br>Alternatively, there's also the RPMS at <a href="http://packages.asterisk.org/centos/">http://packages.asterisk.org/centos/</a> 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 <a href="http://rpmrepo.org">rpmrepo.org</a> folks too as they could in theory base any extras on those packages rather than needing to maintain the entire set... <br>
<br>d<br></div></div><br>