[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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 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: