[Yum] zero server-side support
skvidal at phy.duke.edu
Fri Mar 28 15:03:32 UTC 2003
On Fri, 2003-03-28 at 00:12, garrick wrote:
> Hi all,
> I just wanted to ping the list about yum support for building
> header.info "on the fly" and downloading the rpm headers directly from
> the rpm files. This basicly means yum wouldn't require anything at all
> on the server-side, so it would work with any arbitrary directory of
> rpms somewhere on the Inet.
> headers.info would be created by reading a directory listing for
> local and ftp directories, and html parsing for http directories. And
> before you say that html parsing would be difficult, just look at:
> lynx -source http://mirrors.usc.edu/pub/garrick | \
> sed -n 's/.*<a href="\?\([^>]\+\.rpm\)"\?>.*/\1/ip'
> The only downside is that things might slow down a bit, but I don't
> think it would be drastic. It would certainly be possible to make this
> only a fallback behavior iff the headers/ directory didn't exist.
I think this being a fallback mode wouldn't be such a horrible idea -
but using it as the default would slow things down.
The hard(er) parts:
1. making sure you didn't get redirected offsite
2. you'll have to read through every rpm in a listing and potentially
follow dir links out. The trouble is that it will take some time to read
the header from each rpm even if it is a. a src.rpm, b. an old,
unremoved rpm, c. not for your architecture - you have to do this b/c
you cannot trust the filename - for the moment we can assume that a .rpm
is an rpm of some kind.
3. You'll have to completely rescan a url everytime you update b/c you
won't know what's changed. Storing a cache of the data you scanned
(maybe something like the header.info ;) and comparing that to your
filelist would shorten the startup time for a second run of the
A good place to start (if anyone is interested right away) is to get yum
to handle an arbitrary rpm on the command line (just a local file). Then
get it to handle an arbitrary url to an rpm on the command line.
Then get it to handle iterating over a bunch of them.
At the moment I don't have the time to work on this but it's something I
find interesting even if I don't think it will be very fast.
More information about the Yum