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

Re: Package System specification



>> Yes, but the RPM format is far too complex for a standard, IMHO.  In 
>> Slackware, we offer "rpm2targz" which converts an RPM to a .tgz file.
>> Users have reported successful and unsuccessful installations of these
>> converted RPMs.  I have also had varying success.
>
>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 point was that package
converters will never work as well as the real program for the original
package.  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.

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."

>> What's the main reason this is being done anyway?  I'm assuming it's
>> for commercial vendors to easily offer Linux versions of their software
>> and have it installable on all of the distributions.  I just think
>> selecting RPM is way too much of an overkill for such as standard.  It
>> will introduce far too many more problems than it solves.
>
>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).

   David Cantrell | david@slackware.com
                  | Slackware Linux Project


Reply to: