Re: dependency resolution in 1.0.2

On Tue, Jun 04, 2002 at 02:50:49PM -0400, Jef Spaleta wrote:
> Yes the downside to doing deps from the headers is length of time to
> pull the headers....having nodeps and dodeps  to not do the header
> polling is a good idea....

And configurable when (if at all) you want to do it.

> But I think you can also take the header polling a step further...and
> have a cronmode where you grab the headers and build the provides db
> automagically for all the rpm's on a server, overnight...so when you are
> ready to do an upgrade interactively you already have a built provides
> db in place.

You already can... /etc/grab/defaults:'do provides = 1'; grab --update
  BTW '1' tells GRAB to do this at update time, '2' is how grab 1.0(.1) do it
  and '0' is not at all. defined in config file.

Do this from cron, and all your databases will always be current.

> Or...maybe you can have the ftp site that keeps a serverlist also keep
> uptodate provides db's from the headers....so instead of clients
> building their on provide db's for a "common" server..like a redhat
> update mirror or whatever.  So if I'm using Greg's Redhat 7.3
> serverlist...I can also have the option of using the pre-compiled
> provides db for that serverlist as well, to save time on the client
> side.  But for odd ball servers being able to pull the headers and build
> a provide db on the client side on a nightly basis is also a good idea.

I did not think of having it at the location of the server_list server. Good
idea, I will give it more thought.

The only problem with these methods is that my Provides.db is almost 30Mb, and
unless you do a --clean, it will not have to redo any of the currently known
packages (i.e. it only writes the changes to the repository). If I had this
database downloadable, then it will always have to download it. The only time
it really takes a while is the first time.

Still thinking about it though. Also I still need work to do on the dependency
restitution algorithms.

Greg
-- 
Greg Kurtzer
[email protected]
http://www.runlevelzero.net
LINUX,... The choice of a GNU generation!
:wq