Re: Package System specification
> >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 djb@redhat.com "Bah."
Challenge Diversity. Ignore People. Live Life. Use Linux. 879. V.
"I love the smell of napalm in the morning."
Reply to: