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:[EMAIL PROTECTED] > +972-50-7952406 mailto:[EMAIL PROTECTED] > http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev