Summary:	ASTERISK-07707: [patch] redhat/asterisk.spec is stale
Reporter:	Jonathan S. Shapiro (shap)	Labels:
Date Opened:	2006-09-09 15:58:17	Date Closed:	2007-01-03 00:11:16.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) spec.diff
Description:	The asterisk.spec file in 1.2.12 is stale. It does not reference /usr/sbin/rasterisk, and it's use of the Copyright: tag is incorrect. I have attached an updated spec file. Further, it is not really constructed in a way that is consistent with RPM-based builds. Attached is a unified diff providing a replacement redhat/asterisk.spec file (now renamed to asterisk.spec.in) and updating the main Makefile's "spec" target to reflect the new name. The substance of the changes is as follows: 1. The new spec file lets the asterisk tarball be build without unpacking using rpmbuild -t. The asterisk release process should now run "make spec" before generating the published tarball in order to ensure that the tarball incorporates an updated spec file. 2. The revised spec file includes appropriate directives for Source, Prep, and Build. 3. It has been updated to reflect the addition of /usr/sbin/rasterisk. 4. If building specifically for target i686, K60PT is defined and used. Consideration should be given to making this the default behavior for i586 as well. 5. The spec file has been renamed to redhat/asterisk.spec.in. In order for rpmbuild to operate correctly, it is important that the old one gets deleted! The problem with calling the input spec file .spec is that rpmbuild will believe that it is a valid spec file and attempt to build from it. The usual convention in other projects is to name such files xxx.spec.in I should put my disclaimer on file with Digium, but Digium may consider these edits public domain and incorporate them accordingly. Can somebody let me know the process to put the disclaimer on file?
Comments:	By: Tilghman Lesher (tilghman) 2006-09-09 16:21:16 Needs a disclaimer. By: Jonathan S. Shapiro (shap) 2006-09-09 17:01:49 Disclaimer has been faxed By: Jonathan S. Shapiro (shap) 2006-09-10 18:51:44 Subsequent discussion on #asterisk suggests that there is more to be done here, and that another issue wants to be resolved first: should installation of sample files clobber an existing config? I claim that typing "make samples" should not alter the behavior of a currently working configuration. This implies that "make samples" should either install someplace other than /etc/asterisk/, or that it should install the files as xx.sample. The real problem hiding in here is that RPM can't really move the old files aside very well. I'm thinking that samples should be packaged separately, and I'm concerned that somebody installing the samples *after* putting in a config file may inadvertently damage a working config. Also, there was weak consensus on #asterisk that the sound files should be installed in a way that makes them upgradeable (e.g. to native-sounds). This is also straightforward, but not reflected in my earlier patch. If someone can provide guidance on the samples issue, I'll be happy to provide an updated patch. I can also provide for SVN trunk if that is helpful. By: Steve Murphy (murf) 2006-11-01 14:54:49.000-0600 Shap: Thanks for your generous offer to update the spec files. Yes, if you could also provide updates for the 1.4/trunk versions, that would be super. There was a concensus from #asterisk-dev, that the configs need not be packaged in a separate RPM-- I quote Damin: <Damin> murf: Yes.. You can define the behavior for the files and tell them to either backup the old ones to .rpmorig or install the new ones as .rpmnew. <Damin> murf: It's more work, because you have to have an entry for every single config file, and when new things are added it gets tricky, but it can/should be done as the package manager supports it. Jsmith also suggests I point you to:  http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF As to "make samples" not destroying existing configs, but rather, copying the files to xxx.conf.new, or whatever--- apparently, the make samples moves things to .old. In case of disaster, you can move them back. By: Leif Madsen (lmadsen) 2006-12-28 12:35:49.000-0600 The Vendor: needs to be updated as well. Linux Support Services, Inc. should be replaced with Digium, Inc. By: Leif Madsen (lmadsen) 2006-12-28 12:37:21.000-0600 /housecleaning Is the original poster still involved in this? I have seen nothing from him since 09-10. By: Eric Romang (zataz) 2006-12-30 03:46:54.000-0600 Hello, The make sample, simply overwrite the config files, without .old config file creation. Actually i work with 6 asterisk redhat server's, and I had to create a dedicated .spec and rpm for the  config files, remove the make sample from the asterisk rpm. Why ? Cause when you are in production, only the config file will change often than the asterisk binaries. It is also more simple to manage the boxes to have dedicated .spec for the config files. This is only a 1 year return of experience with asterisk on rpm OS. By: Jonathan S. Shapiro (shap) 2006-12-30 22:04:45.000-0600 It's easy enough to mark all of the config files as %config in the RPM, which causes them to be added as .rpmnew when the underlying config file already exists. The real problem is that the Asterisk ocnfig files do not cleanly separate global configuration parameters from per-conneciton parameters, with the consequence that designing a suitable packaging model isn't really possible. As illustration that this problem is real, consider that all of the mechanisms that automatically re-write the config files break if include directives are used to pull in per-connection configuration info. Ultimately this either means that rewriting is the wrong thing to do, or that the entire config model is busted, or both (I think both). To answer blitzrage: no, I haven't touched this. Back when I posted this, I also raised a whole bunch of configuration and manageability issues on IRC, including a bunch of utter borkage in the config language and some crashworthy failures of input non-validation, and the summarized reaction was "No, Asterisk really *should* be incredibly delicate and hard to administer; if you're not prepared to be a guru you shouldn't be using it." Given the attitude, that seemed like sound advice. Also, I have other deliverables, and I just don't have time to mess with unstable versions. I decided my time was better spent focusing on various other things that I work on. Someday the Asterisk team will notice what every greybeard learns the hard way: that the majority of operational failures in production systems are caused by administrators, usually abetted by bad configuration languages. At that point y'all will be ready to deal with configuration and packaging issues, but until then I'ld just be pushing peas uphill with my nose. By: Steve Murphy (murf) 2007-01-03 00:11:15.000-0600 Uh, I take it that enthusiasm for this particular effort has waned! Should anyone feel a sudden rush of adrenaline to update the .spec file, feel free to reopen this issue! In the meantime, the grey beards around here will awaken, and help keep shap from pushing peas! BTW, I tend to agree with shap, that the config file end could always stand to be more robust. But, I guess one could say the same about every aspect of Asterisk!