Re: up2date trick

On Mon, 2002-03-25 at 16:01, Nathan G. Grennan wrote:
> >  RPM doesn't allow all
> > the different archs to be installed if the versions are the same (this
> > is the feature that made it impossible to base Current on rpmdb
> > directly), and I'm not sure how that is going to affect your method of
> > pulling down more recent packages. I think you'd only get the kernel
> > that matched whatever your server was, for instance, and then some of
> > your clients will go boom.
> >
> 
> Yeah, this is something to work on. I might be able to fake it by going
> through multiple passes and changing the rpmdb or configuration options.

I went through all that in the very early versions of current. Good
luck. (Try a single rpmdb [with noarch and i386] in it with an exception
list of extras. That came closest to working before I went insane)

>  
> > This is why there are no features in Current yet for "automatic" channel
> > updates. Its a tough problem and the more important it is for your
> > client machines to keep running, the more important it is for a human to
> > make those decisions, in my opinion.
> > 
> 
> That is a matter of opinion. By only letting a human add updates to the
> Current server you expose yourself to errata longer unless you live just
> to update it. Also totally automating it with a script was just an idea.
> I think using this idea to just get all the rpms manually is also a good
> idea for the same reasons I mentioned in the first place, not wanting to
> hunt for a mirror.

See, thats a valid view point as well. I just hestitated to make that
the default viewpoint.

If you get this working, and submit patches that make some kind of sense
to me, I have no objection at all to including this kind of
functionality in Current - it just won't be the default. 


>
> 
> I delete them because I thought they weren't needed and they clutter the
> directory. Current seems to be perfectly happy to accept just the rpms
> off the CD, so why have the headers? It may affect how up2date acts, but
> I haven't tested that. 

It'll blow up. One of the queries that the client sends the server is 
"give me the header info for pkg X". The server caches those at channel
create time (cuz it's expensive), and has no code in the "fast path" to
recreate the headers on the fly.

You really do either need to 
a) patch in "update" support to cadmin, against the _addRpmPackage()
   call in channel.py
b) wait a few more days for the SQL code tree to open, which can do this
   already. (Toby's smarter than I am)

> > It would be better to not delete all the headers each time and to export
> > the package updating code in channel.py to cadmin. It _should_ be
> > possible to do what you want without doing crazy things like wiping out
> > all the cached headers. 
> > 
> > I'm not willing to do this code, but if you want to take a crack at it,
> > I'm certainly willing to answer questions and review ideas/patches.
> > 
> > (I'm trying to get the sql code checked into the next devel tree, and my
> > time is consumed completely by that)
> > 
> 
> Again, why do I need the headers for Current when just raw rpms work?

To support that client request. Look in up2date.py (of Current) for
details.


> > That would break every time RHN did. 
> > Or would break everytime you had local patches added which suddenly
> > conflicted with something new/different in RHN.
> > 
> > I'm not saying this is a terrible idea - I'd love for this to be
> > automatic as much as anyone. But I think everyone should know its not
> > going to be flawless.
> >
> 
> How would this break RHN? How would local patches affect this? I always
> use the rpmdb, not the system rpm database.

You have some package foo which has file /usr/bin/foo which does one
thing. Red hat comes out with some updated package which now also
provides /usr/bin/foo. (but does soemthing totally different).

This has happened here.

Etc etc. Even scarier is the library issues with local packages vs
redhat.

Again, I'm not saying don't do it - I'm just trying to point out to
everyone the _possible_ problems, and stating that "automatic server
updates" won't ever be the default behaviour. I'd love to have the
patch...


> You obviously didn't read this very closely, or I must have been really
> tired when I wrote it. I meant to describe what was possible and then
> show the problems with doing it that way. In the end I was trying to
> show why it could be in anyone's best interest to buy a $60 entitlement
> and to use Current.

Possibly both - today has been one LONG meeting after another.

That is a much nicer thing to do. Hmmm...


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