On Tue, 2004-03-30 at 11:26, Nick Rout wrote: > Jim Cheetham <[EMAIL PROTECTED]> wrote: > > I think you're trolling with RPM ... > > maybe i was. Isn't it time for a flamewar LOL? And I wasn't necessarily > disagreeing with you (perhaps i should have made that clear. Perhaps i > should also have made it clear that my post was to point out the > connection between cpio and rpm.
I have (bizzare but true) a 1997 copy of Maximum RPM here, and it's appendix delved into the file structire of an RPM in great detail. You'll be pleased to know that the body of the file is indeed a cpio archive, gzipped. With a dip of the hat to Chris, the comment is :- "... an ordinary cpio archive in SVR4 format with a CRC checksum" BTW, if anyone is still reading this far, if you want this book, you can have it ... it's been lurking on my bookshelf for about 7 years doing nothing positive for me :-) ISBN 0-672-31105-4. Email me direct. > personally my view is that binary distributions will all have problems > when important libraries are updated out of sync with the rest of the You have exactly the same problems with source distributions. Exactly. There Is No Difference. If you *ever* update a piece of software on your system, you are risking an interdependency failure - unless you are sure that "soneone else" has checked and pre-validated the change. It doesn't matter how you do the update, whether it is from source or binary ... someone needs to be keeping track of all the dependencies of other programs that might be using the *old* version, that won't be compatible with the changed version. > leading to rpm hell, or deb hell, or tgz hell. I'd link googlefight.com, 'cept that it seems to be broken. google:"rpm hell"=1580, google:"deb hell"=63. Factor of 30? Remove the quotes if you're willing to pollute deb's results with people called Deb, and you still get 175,000:84,200, factor of 2. > > > (and rpm's perceived problems have nothing to do with cpio, and are True :-) -jim
