Thanks Craig, it all makes sense now.  I switched to a different mirror and
everything updates pretty quick :)  Thanks again.

So now that I have a RH 6.1 box, with an updated kernel, and I have applied
updates for 6.1 via autorpm, can I change my release information in
/etc/redhat-release and autorpm updates meant for 6.2?  Or is that a bad
idea and I should really install 6.2 from scratch and then autorpm updates
meant for 6.2?

Thanks for your help again,
--Moby

> -----Original Message-----
> From: Craig Kulesa [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 30, 2000 2104
> To: [EMAIL PROTECTED]
> Cc: Mobeen Azhar
> Subject: Re: Keeping RH up to date
>
>
>
>
> Mobeen Azhar <[EMAIL PROTECTED]> writes:
>
> > I installed a RH 6.1 box and upgraded the kernel and modules stuff to
> > 6.2 by following the Kernel update howto.  [......]
> > It seems that  the FTP sites that it checks are very slow and after
> > going through some RPMS, autorpm bombs.
> > Has anyone gotten autorpm to work consistently?
>
> If the sites that autorpm checks are slow or unreliable, go into
> /etc/autorpm.d/autorpm.conf and /etc/autorpm.d/pools* and point it to more
> reliable mirrors. A list of mirrors exists at
> http://www.redhat.com/mirrors.html.  Find a few that suit your needs
> best and tell autorpm to try to use those first.  You can tell it to
> use Redhat 6.2 updates in this file, if you really insist.
>
> > I noticed that even though I upgraded my kernel and modules to the 6.2
> > versions, autorpm still went looking under the 6.1 directory on the ftp
> > sites from which it gets it's updates.
>
> That's because you pretty much still have Redhat 6.1:
>
>       'cat /etc/redhat-release'  :)
>
> > I FTP'ed to ftp.redhat.com and found that the number of RPMs is much
> > greater under the 6.1 directory than it is under the 6.2
> > directory.
>
> Redhat 6.1 has been out since 10/1999, so more updates are available. All
> of X-Windows, Gnome, etc...
>
> Redhat 6.2 incorporates the fixes to Redhat 6.1 and goes from there. It
> makes _sense_ that fewer updates are available for 6.2.
>
> Just because you upgraded the kernel from 6.1 to the one in 6.2 hardly
> means that you're running Redhat 6.2.  For example, you're still using an
> old(er) XFree86, slightly different glibc, GNOME, etc...
>
> You have Redhat 6.1 with a newer kernel. That's it.  I'm running the
> latest 2.4.0-test* kernel here.   Does that mean I'm functionally running
> Redhat 7.0?  No.  I simply have Redhat 6.2 with a pre-2.4 kernel.
>
> So it's *entirely appropriate* that autorpm send you Redhat 6.1 updates.
>
> Generally speaking, security updates are provided for all all Redhat
> releases to which they are applicable. There's no penalty for sticking
> with 6.1, in other words, at least in regards to updates. I think 6.2 is,
> out of the box, much better though.
>
> > This is starting to be frustrating.  Coming from a FreeBSD world I think
> > I got spoiled with the cvsup mechanism and the fast and responsive
> > ftp.freebsd.org!!!
>
> I can half-saturate a 10Mb network connection to metalab.unc.edu, for
> example.  That's _not_ terrible.  Just because ftp.redhat.com is hammered
> doesn't mean that you don't have many other choices. Find a mirror that
> suits and use it.  They exist.
>
> Admittedly, there are many broken 3rd-party contributed RPM's, because
> some RPM builders don't follow the rules for consistent 'dependencies' and
> 'provides' lists, among other things.  Debian and FreeBSD enforce the
> rules better, the packages are made available in a more centralized and
> organized and controlled manner.  I think Redhat could learn from these
> efforts.
>
> I find RPM to be a very nice way of packaging software. It's well thought
> out, organized and documented.  It's particularly nice when you are using
> low end hardware for which the notion of compiling packages from CVS
> source is not an option. Or if you prefer not to answer a billion
> questions when upgrading packages -- you'd rather that the _packages_
> themselves contain the intelligence necessary to install themselves
> appropriately. RPM seems to provide this to a reasonable degree. It's not
> perfect, but it's quite competent. IMHO, of course. :)
>
>
> Craig Kulesa
> Steward Observatory
> University of Arizona
>
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.
>
>


-- 
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.

Reply via email to