Re: resolvedeps

I didn't subscribe you to the list, but unless people are careful,
replies are not going to go to you.

On Thu, 2002-09-19 at 11:58, Jeff Johnson wrote:
> > 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.

"There aren't many of them" seems a poor excuse for doing it wrong.
Baseing your implementation to assume that it will always be just
kernel/glibc/openssl seems to me to be standing on Murphy's front stoop,
pounding on the door, shouting "Take me, take me."


> 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.

I don't have that implementation working anymore, but actually the speed
trials with 3.x strongly favored using python shelves. I don't know why.
If I had to guess, it would be the server not having (or wanting) all
the careful checking code in rpmdb.

Correctness was more important than speed anyway, so I went with
shelves.

> 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.

No. The only way to sanely manage all this is with  some kind of
database that tracks this kind of information. Using out of band data to
"guess" that the client REALLY wanted a "foo2" arch package when they
asked for a "foo" package is just begging for trouble.

> 
> 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.

I know. There are tables in packagedb.py that attempt to do this. They
seem to work for all the cases I know of.

But there's just no way to use rpm/rpmlib for this.
(hint, hint)


> > 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.

up2date used to ask the server for this all the time. In versions >
2.7.0, the client does all this work and can then use the rpmlib
functionality, with one exception: 

The server still has to know which channels are "arch" compatible with
the client. 

I can't change that - I do not (and probably will not) patch up2date
itself.


> HTH

What would help is additional functionality (exposed in the python
bindings) that would let me set the "base arch" for archScore() and
similar. That way, current wouldn't have to reinvent the the different
mechanisms inside rpm.

archScore(arch, base_arch=None)
    if base_arch == None:
        base_arch == rpmlib.getArch() 
    ... 
That would be compatible with the existing API, and still let
current/up2date/RHN/whatever play games with archScores intended for
other machines.

The other request I have for rpmlib right now isn't current related:

IMNSHO, 1.4.rc1 should show up as "older" than 1.4.0.

Semantically, how to do that is not clear to me. It might be impossible
to get right any mechanism which would always sort alpha vs numeric
"correctly", for whatever that particular package / package author
defines as correct. 

Given that the common ones I can think of "alpha", "beta", "rc" should
all sort as "older" than the numeric equivalents suggests that letters
should just go in the list before numbers. However, I have worked with a
tool (was it purify?) that would have 1.4.b.6.1 vs 1.4.2.1.3 type
numbers. At this late stage in my life, I don't recall which was
older/newer. I could easily imagine it being opposite to the example I
gave above.

But I thought I would ask.


-- 
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.