Re: resolvedeps

On Thu, Sep 19, 2002 at 11:33:28AM -0400, Hunter Matthews wrote:
> On Wed, 2002-09-18 at 19:07, Alex Kramarov wrote:
> > Hi.
> > 
> > I am trying to learn from your experience : database_design.txt talks about
> > you trying to use rpmdb to store info about packages, and this idea was
> > thown out because of speed and multy-arch. I don't know what were you trying
> > to use the rpmdb for, but if i want to use rpmdb in nrh-up2date for
> > dependency resolution only, should i care about multy-arch ? From your
> > experience do multy-arch packages differ in the dependencies they provide ?
> 
> Yes, they do. (Its rare, but it does happen.) The specific case I saw
> was a package in both i386 and i686 versions (glibc maybe?) where the
> i686 version provided ONE additional thing that the i386 version did
> not. Is that at all likely to come up? Probably not. But if you want to
> be _correct_ (and current tries) then you have to deal with it.
> 

FWIW, there are only a handful of (albeit important) packages like
kernel/glibc where arch is important.

Yes, the arch (and os) handling in rpm (not rpmdb) are hopelessly
inadequate to the task.

However, rpmdb will run rings around whatever other implementation
you attempt. Cheating (by, say, redefining the problem and ignoring,
say, file paths in Provides:) is doomed to failure too.

> The bigger problem with using rpmdb was simply:
> 
> How will the server know if it has an i386, and i586, i686, and athlon
> versions of the same package (take the kernel, for instance)? Rpmdb is
> only going to let you install ONE of these, and then your server will
> have to have some other mechanism to "know" that it also has the other
> archs available.

How does the rpm CLI handle this choice? Essentially by (the user/client)
looking for secondary information, usually the arch in the package name or
(more correctly) querying for the arch tag in the package header.

Sending the arch string through the rpm machine scoring API is the only (well,
you can duplicate and maintain the functionality somewhere else instead)
is the only way to invoke the inline asm voodoo in lib/rpmrc.c (which
despearately needs changing IMHO) is the only way to get the same
answer as rpmlib.

Again, this has nothing to do with rpmdb, i.e. the database format used
to save headers on the installed platform.

> 
> If you use rpmdb, you may also be tempted into using archScore and
> friends, and since they are hardwired to giving answer based on the
> SERVERS arch, and not the clients arch, this road leads to madness.
> 

The above is true only if you attempt rpmlib machine scoring on the server
side, you need to do the scoring on the client and transport the result.
Duh, but agreed madness.

> 
> > The script is available
> > on request (i could put a link to my project, but i am afraid that current
> > developers will consider this an advertisement for my own project. 
> 
> If you post it everyday, I will become ... annoyed. But once in a while?
> Send it. (Cheat, and include it in your sig - as long as you have
> something to contribute to _current_, I don't care) 
> 
> > I really
> > sorry that we are not working together on this - we could do a good job, and
> > i am still open to suggestions)
> 
> We have about 18 months invested in python, and the client is in python.
> To say I'm unwilling to drop that and recode everything in perl is a
> massive understatement.
> 

<grin> Why not C? :-) :-)

> Current, eventually, aims to be able to perform all/most of the
> management jobs that RHN can do. It sounded like you were aiming for a
> much lighter solution. 
> 
> That said, if you have patches, features, bug fixes whatever for
> current, send them. If they're appropriate, I'll apply them.
> 
> If you have other questions about understanding current (like the db
> question above), send them. I'll explain what I/we did as best I can.
> 

HTH

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
[email protected] ([email protected])
Chapel Hill, NC