Re: Package version conflicts

Hello everyone,

About a week ago I had an email discussion with Hunter about implementing a SQL 
backend for current.  I’ve got the bulk of the database stuff done.  I am now 
integrating it into current. It is not quite ready for anyone to try.  
Hopefully in about a week, depending on my schedule.

Ground rules:

1. PostgreSQL (thats what Hunter wanted)
2. Pure python 1.5.2
3. Multiple rpm arch’s per channel
4. Sane handling of multiple rpm version/release/epoch per channel
5. Directory recursion
6. RPM, SRPMS, and headers on file systems so can be served with apache
7. Works correctly with stock Redhat NFS/FTP install trees 
8. Works correctly with simple mirror of updates.redhat.com
9. Works with any other directory structure you care to have.
10. Can add or remove rpms from channel without having to rebuild the entire 
database.
11. Will support future "non-anonymous" mode so "update -p" works.


Toby



Quoting Todd Nemanich <[email protected]>:

> On this note, I'm working on an SQL database 
> schema that can hold multiple trees/channels. My 
> current workload isn't permitting me much time to 
> work on it right now, and probably not much in 
> Febuary. However, I am hoping to get it together 
> by the time current-1.x development starts. To 
> this particular problem, my schema does not allow 
> multiple versions or releases of a package name to 
> be held within a package layer. I will allow 
> multiple architechtures though (primarily so that 
> optimized kernels are held correctly).
> 	I would like to know if it would be preferred to 
> track the client channel on the server side or on 
> the host side. The schema I'm working on does not 
> provide tracking which channel to use for a host, 
> so I would have to add this.
> 
> Nathan G. Grennan wrote:
> 
> > Hello,
> > 
> > 	Since the release of the most recent patch we have a functioning
> > up2date server, but something Must be done about cadmin/current and more
> > than one version of the package in the tree. Having to go through by
> > hand and remove duplicates every time a new update comes out will be a
> > nightmare. There are duplicates of original vs errata, old errata vs.
> > new errata, rawhide vs errata, gnomehide vs errata,  different arch vs
> > everything else, arch vs arch. There is also the problem of when you
> > want to keep things up to date by mirroring redhat so that all the rpms
> > will be under directories in like redhat's ftp tree. I think this can be
> > over come by using symlinks generated by a script, but there is still
> > the multiple copies problem. Has anyone come up with any elegant scripts
> > to solve this problem? I think really this must be address without
> > current so that it just doesn't care and figures out the newest/best for
> > the client itself.
> > 
> > Example:
> > 
> > 
> > xchat-1.8.1-2.i386.rpm      - original 7.2
> > xchat-1.8.6-1.i386.rpm      - current gnomehide
> > xchat-1.8.7-1.72.0.i386.rpm - current errata
> > 
> > 
> > or
> > 
> > kernel-2.4.7-10.i386.rpm   - original 7.2
> > kernel-2.4.9-13.i386.rpm   - old errata
> > kernel-2.4.9-21.i386.rpm   - latest errata i386
> > kernel-2.4.9-21.i586.rpm   - latest errata i586
> > kernel-2.4.9-21.i686.rpm   - latest errata i686
> > kernel-2.4.9-21.athlon.rpm - latest errata athlon
> > 
> > 
> > _______________________________________________
> > Current-server mailing list
> > [email protected]
> > http://lists.dulug.duke.edu/mailman/listinfo/current-server
> > 
> 
> 
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server
>