Re: up2date trick

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

yeah, it looks like I have three options. Do what you mention above and
hope I can work out every detail, write a script to login to the
rhn.redhat.com website and download the all rpms in the arch
family(i386, i486, i586, i686, athlon) for certain packages(kernel,
glibc, gzip), or convince the up2date maintainers to add a feature to
just do this, instead of trying to hack around their functionality.

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

Ok :)


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

Ok, so just don't delete the headers, not a big deal. It doesn't seem to
blow up when they are missing, but does seem to redownload them, which
just takes extra time.


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

Ah, you aren't talking about how this affects the download idea, but the
wisdom of trying to auto upload at all. Like putting up2date -u  in
crontab. Yeah, I have run into something like this before. I had a
client where I had installed third-party perl module rpms. So I found
one day when I went to check up on the system that something like a
dozen errata hadn't been installed because the third-party perl module
rpms were dependent on perl 5.5 and an errata for perl 5.6.1 had come
out, so it refused to update till I manually uninstalled those perl
modules. Then I could install the errata, and then had to install
updated copies of those rpms for perl 5.6.1.