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 following: 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. hth 73 de Jeff > Rolf > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List [email protected] ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List [email protected]
