Re: New release posted

On Wed, 2001-12-12 at 19:31, Ivan F. Martinez wrote:
> >Current 0.9 has been released!
> >
> >Many changes: see the README and the CHANGELOG for details. In short,
> >it now supports up2date 2.7 clients, its more robust, new Makefile, 
> >RPM packages available, small database changes.
> >
> >Please note: Due to requirements to support the 2.7 clients, 2.5 clients
> >are BROKEN with this release. If 2.5 support is critical for you, you
> >must let me know in the next few days, otherwise I'm going to pull that
> >code out completely. (Red Hat has back-ported 2.7 to 6.2, 7.0, and 7.1,
> >so this shouldn't be a big  deal)
> 
> I;m testing only the database now, and some suggestions :
> 
> When reporting some error like different versions of the files (in channel.py) please use the pathname var (with fullpathname) instead 
> of only file (only rpm filename) if make easier to solve problems.
> 
> Also I'm in trouble with my mirrored files.
> RedHat remain with old rhn_register in the noarch directory and when current try to load it find the new version in i386 and older in 
> noarch.
> I think it can be correct, for not i386 architectures the latest can be the noarch. Then in this case the database must ignore the 
> noarch file. Like it must ignore older versions.
> How we can do an quick solution for this thing ?

There's no way for Current to deal with this right now - it ignores the
arch when comparing version-release-epoch, and so current simply sees
this as a new-version/old-version problem. Current also has to be
careful about showing a "preference" for one arch over another - think
about the kernel and glibc packages that come in multiple archs for the
exact same version.

You'll have to take the old version out of your tree by hand.

> 
> I have tried to understand the program logic to solve this, but I can't.
> I don;t know much about the structure of data to do this.

It's a little messy right now. I really butchered the database to try
and deal with 2.7 clients better. It'll get worse in 0.9.1 probably, and
then a lot better in 0.9.1 or 1.1. Sorry.

 >I'm also planning on removing the "feature" where a single channel could
> >be spread accross multiple rpm and src dirs - 0.9.1 will only allow one
> >dir for each, so that later versions can see significant speed
> >improvements.
> 
> Can you explain better this ?
> You are talking about using only a single directory for each channel ?

That is exactly what I mean.

> It will not work for the mirror of RedHat site, they updates are divided in i386,i486,i586,i686 and noarch directories.

Correct - you will not be able to use a straight mirror of the RedHat
site - you'll either have to copy all the errata into a single dir, or
symlink all the files into a single dir.

Why? In the 2.7 clients, GET requests are used for moving "big" data
around (listPackages, rpms, headers). For some version of Current after
1.0, I'm planning on using apache and mod_python as the "engine" for
dealing with the http/https protocol (apache is much faster than
straight python). 

To do that, I'm almost certain I won't be able to or won't want to
rewrite the "PATH" of the GET request. Therefore, we go to one directory
per channel.

I have just downloaded the mod_python docs. If its possible to "rewrite"
the GET request in a secure and sane manner, I will leave the multiple
directory feature in.


-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.