On Fri, 2003-03-07 at 18:01, Audioslave - 7M3 - Live wrote: > I opted to get the program from Psyche, since it was newer.
I wouldn't have done that. Bound to really break things on yer beta box rolling back to a redhat 8 release package....and you know what happens if it breaks...you get to keep all the pieces...and i doubt any bugs due to collateral damage you file at this point will get processed...yer outside of an established reference for bug reporting as far as i can tell....too bad rawhide is down huh. Atleast with a rawhide package...if it broke...you could probably file a bug against the package under the rawhide category and felt somewhat better that someone might look at the report (and I can safely bring up rawhide now because chabotc should have me procmail filtered now..he promised he would ignore me from now on, no more educational emails about how rawhide ain't a fix) rawhide is unwise if you have an expectation that things will work(otoh, no one should expect betas to work to begin with)...but at least you can file bugs against rawhide. Rolling back to a rh8 package has got to be worse from a bugreporting point of view, I'm not even sure where you'd think about filing a related bug now. If you do start filing related bugs make sure you detail what you have done here with the bugreport. You have to ask yourself...is the point of the beta system to have a working system...or is the point to beta test packages. I don't think the point is to have a working system...or even a secure system during the beta process. I think the point is test packages, and complain to redhat about the bugs you find. There are no garuntees for bug fixes before a next release..its nice to have them...its nice to test them...but there is no garuntee that any will ever be forth coming. Redhat could just issue one beta iso...and accept bugreports from that, and never release another package to public beta testers again...and do the rest of the testing in a closed beta. The expectation that there will be ANY subsequent packages..is an expectation for support. The beta is WHOLLY unsupported...the beta release as an end of life of about 1 minute after its released (if that). When they say its not supported, it means its not supported. > I wasn't successful when trying the openssl program version from RH8. It was older, > but included the bug fix. > I thought, what the heck, I'll try the older version through a force, nodeps > situation. omg...force, nodeps...not wise. > Anyway, up2date, lynx and a host of other programs failed to work with the older > program version. thats not really all that shocking...there is a reason dependence checking is there and a reason why you shouldn't bypass rpm's logic with force and nodeps. > fortunately, I had the disc burned on the better working burner action for RH7.3 to > pull the phoebe3 version off of and was able to upgrade to the proper and probably > vulnerable version from the disc. such is life...again...betas are broken,insecure,unsupported pieces of...cough...software. I keep meaning to do a nother burn on this beta box and test the disc out for data corruption....maybe i'll do this now. > I don't totally suspect the programs compiled from outsiders, but I am more wary of > them ,than I would be for programs versions released by redhat. I think you missed the point of my post...watch as i give the dead horse one more swift kick to the head... the point was to point out chabotc was being hypocritical. chabotc wants to remind us that a "beta platform" is a complicated collection of 1400+ packages, and its an engineering miracle to get them all working together, and beta testers should really stick to the script and not go installing wacko random version of the packages because is some value in making people test a "specific collection" of 1400+ packages and figure out how they interact badly. Now thats all well and good...nice and consistant...but chabotc offered up his own compiled packages to fix this unwelcomed (but should have been expected) security problem in the beta. Thats were he went wrong, he offered his own compiled packages which are totally outside the redhat QA process (even though they are based on redhat code..you have to trust him specifically that his binary packages are the same...you have to trust his developement system to not be hacked...so on and so on). If you chose to use his packages...and it didnt work...where would you file bugs...certaintly not with bugzilla...they aren't redhat compiled packages anymore...that are chabotc.com packages....and like in mission impossible, redhat will disavow any knowledge of them if things go horrible wrong. And for that, i called cabotc the strongest derogatory term I know...hypocrite. > I haven't patched any programs before. But how difficult is it to patch the source > with the security update, then compile and package the rpm for use? Depends > Are the patches pretty much program version independent? Depends...but most probably very dependant I think i can sum up whats going wrong here...you are thinking that the beta is a product...it isnt a product...its a big old collection of unsupported packages that are in a proto-product stage that is pretty much garunteed to break in some crucial way....and you get to help discover how it breaks...but no one is actually beholden to give you a fix for the things that break before this gross little beta caterpillar crawls up in its rawhide frozen cacoon and emerges as a beautifully crafted release product. It sucks...but thats the risks of running a beta....its a waste of breath to try to twist redhat's arm about supporting the beta...the beta is not supported and will not be, in the sense that you can every expect an update package to show up for the beta. You maybe have grown accustomed to the idea that Redhat has in the past offered X number of beta isos during a beta cycle, or Y many sets of packages to up2date...but that expectation based on past performance is misguided. -jef"wouldn't be horribly surprised if this kind of unwelcome security problem had happen in a previous beta..with the same sort of result"spaleta
signature.asc
Description: This is a digitally signed message part
