Re: Package version conflicts

Hunter Matthews wrote:

 > However, dependancy resolution is a 
REQUIREMENT. Even Current's shelve
 > implementation doesn't do it all - we ignore 
conflicts and obsoletes
 > right now (I think I know what to do for 
obsoletes, but what to do with
 > or about conflicts is still an open discussion).


Obsoletes and conflicts work very much the same
way as dependencies. You have
RPMTAG_CONFLICTFLAGS, RPMTAG_CONFLICTNAME, and
RPMTAG_CONFLICTVERSION, which tell you the name
and version of the conflicting package. I am not
certain on the *FLAGS RPMTAG entries. Based on
type (Requires, Prereq,rpm internal, etc). I would
have to dig throug the rpm sources to figure out
exactly what each are. But there are some clear
patterns already.


 >
 > Basic dependancies (which I define as "whats in 
Current right now") come
 > in three flavors:
 >    file deps
 >    "name" deps
 >    provide deps
 >
 >    File deps are easy - package X contains some 
file /usr/bin/foo
 >    Name deps are basically just the names of 
packages. If your
 >       tree/channel contains the strace rpm, 
then "strace" will be here.
 >    provides are a little trickier - they _can_ 
be versioned, but aren't
 >       always. Provides are almost always just 
libraries.


I have found that the provides that usually catch
me are usually service names like smtpdaemon.


 >
 > Right now, Current ignores any version stuff. 
(it didn't look like the
 > client wanted it anyway). I put it in the DB 
because I finally figured
 > out how it was stored in the RPM, and wanted to 
"document" that
 > knowledge.
 >


If people are interested, I will forward on a
simple program I have called rpm_parse. It will
dump all the headers to the screen and you can see
how they work. It is in C, but its purpose is
educational.


 > Any DB layer has a new rule "12": it must 
provide at least as much
 > dependancy data to Current as the existing 
shelve implementation.
 >
 > The simplest way to do this that I can think of 
is 3 tables per channel,
 > with the needed data. However, one reason 
Current was written with
 > shelves is that I am not a DB programmer of any 
skill.


Ok, I'm looking over channel.py. It looks like you
just want to have a list of the dependencies from
a package, and what kind it is (name,file, or
library). I think this is doable. I'm looking at
either a weak entity dependencies with two
relationships, or relationship from packages to
itself with some attributes about the dependency
information. For the weak entity, the two
relationships would be to packages for a <depends>
relationship, and checksums for a <contains
dependency> relationship. I'm going to look at the
RPMTAGs some more and decide which one is more
flexible. In any case, I should be able to
generate at least the list of name (+version),
file, and provides dependencies for any package in
a channel. I should also be able to identify upon
insert if the database does not yet have the
packages that are required to meet the dependencies.