> >Then either rpm2targz is broken, or you were doomed to failure because the > >things the RPM needed to work properly weren't available on your system. > > > >The RPM file format is nothing more than an archive of files and some data > >all > >bound up neatly so that it can be cryptographically signed. There is no > >magic > >there. > > > >In fact, RPM *comes with* rpm2cpio, a tool that simply spits out a cpio > >stream > >of files in the archive. If rpm2targz can't use this already existing > >feature > >of RPM to make a tarball correctly, well, that isn't RPM's fault. > > OK, this was not meant to start a flame war.
My note wasn't a flame, nor do I consider this a flame war. > My point was that package > converters will never work as well as the real program for the original > package. And my point is that you're wrong, as far as systems like Slackware are concerned. RPMS work just as well as a tarball. They are a superset of the functionality provided by a tarball. If all you use is a tarball based package system, installing the files contained in an RPM will work just as dang well. Your point seems to point to situations like .deb vs .rpm, but the .deb folks don't seem to think this is an issue. I'm saying that *you* shouldn't think it is an issue, either. I could perhaps see a point if you were from .deb land and were worried, but as a .tar.gz guy, your points don't make sense. > Even if the converter and converted-to-system install it > flawlessly, you still leave open the possibility of missing something from > an embedded script that doesn't exist in the converted-to-format. Like I said, the folks who do this with alien seem to think it works just fine. > You simply can't guarantee that RPM will work unless all distributions use > RPM natively, include the same software, and the same versions of everything. > When I say work I mean "I get this RPM from a software company and tell rpm > to install it." *shrug* Nothing is guaranteed, but it seems to work much better than I ever even expected. > >This just goes back to the "dependencies are necessary" argument. Most of > >the > >free world seems to agree that they are, Slackware users don't. > > I'm not against dependencies If there is a dependency, it should be the LSB. > Written correctly, that could work and commercial vendors would have no > problems > porting or writing software for an LSB-compliant system. Anything that isn't > in the specification would need to be provided by that vendor, as well as an > installation system (it's not really a big deal...look at Star Office and > Netscape). Dependencies will still always be necessary in the current form as well as part of the LSB. The LSB won't ever standardize everything, and I would expect complex systems like Oracle to want to use the RPM (or similar) mechanism for their own applications to make sure things of *theirs* that need to be there are there. Some vendors may also want to rely on open source libraries that aren't spec'ed by the LSB that many distributions *do* ship. They'll want to use them if they are there, and provide them in case they aren't. But the last thing they want to do is overwrite them unnecessarily since that could break things. Have you ever seen the mess that is the world of .dll's in Windows land? Every single game on the planet nicely provides its own DirectX drivers and installs them no matter if you have a newer one or not most of the time, which can break installed things. This is avoidable and we should do it if we have the ability. RPM has that ability. --Donnie -- Donnie Barnes http://www.donniebarnes.com [EMAIL PROTECTED] "Bah." Challenge Diversity. Ignore People. Live Life. Use Linux. 879. V. "I love the smell of napalm in the morning."
