Re: resolvedeps

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.

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.

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

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.

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