On Dec 10, 2011, at 10:22 AM, Rolf Pedersen wrote:
> On 12/09/2011 07:16 PM, Jeffrey Johnson wrote:
>>> > Ok, got -qip back. I'm amazed there's no one else using this functionality, apparently. Thanks for your help.
>> Well if you think a bit, it shows how addicted most linux users are
>> to vendors because of packaging tools.
>> Its called
>> customer lock-in
> I might identify with "lazy" and "ignorant", along with "addicted" ;)
Self-identify as you wish, there's a serious problem releasing
accurate information in a timely fashion re what is implemented
in RPM. Even two books and multiple distros and 3-4 forks
(depending on POV) haven't succeeded in solving the documentation
problem of how to use RPM yet.
You did find the relevant check-in and found the right mailing list which
is neither lazy nor ignorant ;-).
> It has taken some time to learn the, to most of us, arcane features and switches of rpm and other FOSS binaries, since early 2000 at my slow pace. Repeating process with other package managers does not appeal to this short-timer. As the FHS gold standard for package management for this period, afaict, rpm has impressed me as safe and capable, more so with Mandrake's urpm* augmentations. Thanks for your work on this.
Well RPM itself is a rather simple program, based on simple ideas/design, that are
mature and changing glacially slowly.
But I most certainly agree arcane and hard to use: there's years of tortured
hacks that really SHOULD be ripped out of RPM; meanwhile the issue is legacy
compatibility and being able to adapt to all possible needs, the core set
of commands necessary to use RPM successfully isn't huge.
Meanwhile -- since you are attempting network access -- expect the
1) Use FTP instead of HTTP if available, the implementation is more complete.
2) The RPM you are likely more familiar with downloaded all pkgs into
/var/tmp first, and then installed from the downloaded packages. The
@rpm5.org code has removed that DL loop to be able to attempt installing
packages directly from the wire. OTOH, the inital download loop could
be patched back in easily if you need.
Wrto HTTP transport, expect the following
1) No support for 30x redirects
2) No support for byte ranges, or partial download restarts
3) (HTTPS) No support for certificate verification: all certs are "trusted".
For debugging purposes, adding --ftpdebug SHOULD display the protocol msgs,
and --rpmiodebug will display just about every I/O operation and system
call being perfomed by RPM.
Feel free to ask if you run into difficulties: many fixes are quite trivial.
73 de Jeff
> RPM Package Manager http://rpm5.org
> User Communication List email@example.com
Received on Sat Dec 10 20:15:34 2011