Re: lets talk about dependancies again...

On Fri, Oct 04, 2002 at 08:08:57AM -0400, Jef Spaleta wrote:
> I haven't tried doing any of this...let me get 8.0 installed on the beta
> box...and play around with it this weekend.

Very cool... It is worth it because the UI is very nice (even likable by a
hacker like me!).

> this should definitely speed things up a whole hell of a lot...but it's
> not clear to me that this is necessary just because of rpm 4.1...I
> didn't notice a huge speed difference between grab on the beta box when
> I tested it.  Maybe the is a clever selection of rpm arguments that
> could speed up the remote header grabbing.  And instead of a
> tarball...maybe a relocatable rpm would be better.    
> -jef

I am not sure what/why it got soo slow, but check this out:

[gmkurtzer@spike gmkurtzer]$ time sudo /bin/rpm -Uvh --nosignature --test
ftp://altruistic.lbl.gov/pub/repositories/redhat-8.0-i386/RPMS/4Suite-0.11.1-10.i386.rpm
Retrieving
ftp://altruistic.lbl.gov/pub/repositories/redhat-8.0-i386/RPMS/4Suite-0.11.1-10.i386.rpm
Preparing...                ########################################### [100%]
        package 4Suite-0.11.1-10 is already installed

real    0m41.125s
user    0m0.473s
sys     0m0.299s
[gmkurtzer@spike gmkurtzer]$ time sudo /bin/rpm -qp --provides --nosignature
ftp://altruistic.lbl.gov/pub/repositories/redhat-8.0-i386/RPMS/Canna-3.5b2-70.i386.rpm
Canna = 3.5b2-70

real    1m36.449s
user    0m0.178s
sys     0m0.080s

Why is it taking twice as long to do the --provides rather then the install? I
am quite certain that this was not the case with RPM40.

Jeff J.- Do you have any ideas?

In either case, even 41 seconds to just do the query is unreasonable (IMHO). I
am not on the fastest network, but it is faster then most (SDSL 1Mb/s).

My idea is that GRAB friendly repositories can be created with grab itself,
and will do one of two things:

1- Each package in the repository will have another file called
[RPM]-[VERSION]-[BUILD]-[ARCH].info and will be a text file that contains all
the info about the package that GRAB would like to know. GRAB can download the
entire mess of them, and cache them locally and quickly parse them to do dep
checks. This is nice because GRAB only has to download the *info packages it
needs instead of downloading an entire database when a package is added or
changed. The problem with it is that you would have to keep the local cached
version for every package on the repository (usually will be roughly 1500,
small text files). I don't think this is a problem, and having these files may
actually prove to be valuable for other command line searching (grepping,
etc...).

2- When grab builds the repository, it will build one large text file that
will have a listing of every package in that directory, and what that package
depends on. I don't like this method as much, because I would get less
information for each package, and you would have to download the entire thing
every time.

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