-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marden Marshall Sent: Friday, September 11, 2009 4:00 PM To: Michal Bielicki Cc: Christopher Coleman; sipX developers Subject: Re: [sipX-dev] 4.0.2 breaks yum
On Sep 11, 2009, at 6:01 PM, Michal Bielicki wrote: > > Am 11.09.2009 um 23:51 schrieb Marden Marshall: > >> >> On Sep 11, 2009, at 5:30 PM, Martin Steinmann wrote: >> >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] >>> [mailto:sipx-dev->[email protected]] On Behalf Of >>> Lawrence, >>> Scott (BL60:9D30) >>>> Sent: Friday, September 11, 2009 4:21 PM >>>> To: Christopher Coleman >>>> Cc: sipX developers >>>> Subject: Re: [sipX-dev] 4.0.2 breaks yum >>>> >>>> On Fri, 2009-09-11 at 15:09 -0500, Christopher Coleman wrote: >>>>> For me, I did a clean install of CentOS 5.3 from DVD and installed >>>>> sipx using the repo. yum update has worked just fine for me >>> throughout >>>>> 4.0.1. I rand yum update today and it found 4.0.2 and I had it >>>>> install. >>>>> >>>>> So far I've found it replaced all my .repo files with one and only >>> one >>>>> named sipeces.repo which includes my other repos, BUT has me >>>>> looking >>>>> for software updates for CentOS 5.2 (hard coded into urls) I also >>>>> found it removed my /etc/redhat-release file which contained >>>>> CentOS >>>>> 5.3 (Final). >>>>> >>>>> Whats up with that?!? >>>> >>>> If true, those are bugs. >>>> >>> >>> It is true. Here is what yum says: >>> Installing: >>> sipxecs-release i386 >>> 4.0.2-009184016420 sipxecs-stable 3.6 k >>> replacing centos-release.i386 10:5-3.el5.centos.1 >>> >>> >>> How did we end up with this? Cannot remember any discussions >>> around a >>> sipxecs-release RPM that removes repo files. >>> --martin >>> >> >> This is not a bug, it is done by design. Our software is only >> certified to work with CentOS 5.2. Any attempt to upgrade to a newer >> release leaves the user exposed to possible OS incompatibilities and >> service interruptions. They are of course free to override / hack >> the >> repo configurations and live dangerously. If something breaks as a >> result, don't come crying... >> >> _______________________________________________ >> > > Exposure to security bugs and known OS flaws is preferred ? Sounds > somewhat counter productive to me, a bit as if you would state that > you know better than > the distribution authors what works and what doesn't which I tend to > doubt in. > Ask yourself one simple question; What is more important, to have the latest and greatest versions of Firefox, Gimp, etc. or to have a thoroughly tested and reliable PBX system? If the answer is "a thoroughly tested and reliable PBX system", then you will stay with our OS recommendations and use CentOS 5.2. Better yet, pay for a commercial license and as a supported customer you will also be provide with ongoing security updates for the supplied OS. I agree with Marden that limiting the Centos version in the RPM to one that has been fully tested and certified is advisable and is prudent. However, it is just as prudent to document this in the installation instructions. It's probably as important to put into the installation documentation all of the dependencies, as it is to have them in the software. The early adopters of this release provide valuable feedback to the developers, at least I believe I have heard that in the past from the development team. This release I believe had the best update steps published so far (that I have seen). I will state that personally, I appreciate all the efforts there, I believe they are a great asset to many. However, like all things new, it seems like there may be some additional work to be done on it, as even Martin seemed surprised by those lines in the RPM. If surprises like that are removed from the upgrade process, it will be more a more successful upgrade, and the identified issues during the upgrade process will go down. Bottom line, your commercial customers will have a better experience in their upgrade process from the lessons learned, and lessons documented. A win/win for all. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
