On Nov 23, 2007, at 3:14 PM, Anders F Björklund wrote:

> Jeff Johnson wrote:
>
>> On Nov 23, 2007, at 2:50 PM, Ralf S. Engelschall wrote:
>>
>>> On Fri, Nov 23, 2007, Jeff Johnson wrote:
>>>
>>>>     - jbj: re-add rpm2cpio.c.
>>>
>>> Nice. Should we also install _this_ program instead of the weak
>>> scripts/rpm2cpio script?
>>
>> Depends on your religion. Some like simple programs, others like  
>> scripts.
>
> When I'm using RPM (as in: actually have it installed), I prefer
> the rpm2cpio program. When I don't, I normally used rpm2cpio.pl...
>

Lots of religions. rpm2cpio has support for FTP transport built-in, used
to do HTTP until rpm and neon got hitched.

> So there is use for both a program and a script, in my opinion.
> (then again, lots of file managers have RPM and XAR support too)
>

There's gonna be a need to interconvert amongst many different
package representations, as well as metadata representations.

So rpm2cpio happens to work just fine with, say, tar payloads, mostly
because tar and cpio understand each other's headers quite well.

Now that XAR is here, zip and jar and the rest of the archive crowd  
are likely
just around the corner, with a tool needed to spew whatever payload  
archive
format one's widdle heart desires, given *.rpm input.

So I'd say there's a need for a meta-program that includes both txar
and rpm2cpio as functional modes, using the usual argv[0] mode choosing
like db_tool does.

Meanwhile, the private reason I ripped rpm2cpio.c was that I got  
tired of the endless
     Should rpm be network aware?
discussions. The rpm2cpio.sh scriptie slam dunk quieted the whiners  
for the last year
or so.

I actually prefer rpm2cpio.c instead of rpm2cpio.sh too. Executables  
rarely need
tinkering.

73 de Jeff