Re: resolvedeps

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

i see, but the way i see it, packages that are released for multy arch, are
usually the core system packages, that you have them installed already in
the system, and i can generally say that in 99.9% of the cases that no other
package will request the server to resolve a dependency that is specific to
the system, since these packages are already installed locally. I simply
want to provide the resolvedeps functionality using already existing stuff.
Right now the only packages that are arch specific are kernel, glibc and
openssl - i trust the 99.9 systems already have them installed :) , and
right now i will simply hope that new multy-arch packages will have the same
deps for all arches. Anyway, i an unlikely case that the client will request
a dep that i can't resolve, i already return a neat error with the list of
deps requested so the client would resolve them manually, (sample output
here
http://sourceforge.net/mailarchive/forum.php?thread_id=1085795&forum_id=1204
1) - all i want to do is to automate the manual resolve step described
there.

about what arches i have available - i don't need it. in my architecture the
client directly downloads the package list that i pulled from RHN, so that
list does contain all arches. i don't need a db to store the packages i have
locally- all i need is the list and the packages i pull will nrh-up2date
script (url below).

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

My update script is here http://www.nrh-up2date.org/nrh-up2date - this is a
modified version of up2date client script from up2date-2.7.86-7.x.3, that
connects to RHN servers and downloads all available packages for the channel
specified by the systemid present on the server. I haven't tried to do
multiple channels, but i suppose that it possible. If anyone can test such
scenario and report the results, it would be gladly accepted.

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

i actually never thought of you dropping the work you have already done, i
thought more of providing additional functionality with lighter
implementation and minimum management.

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

Yes i am, you are correct. But i am happy that we can exchange ideas and
help each other.

Alex.