On Mon, Dec 7, 2009 at 6:25 PM, Karanbir Singh <mail-lists at karan.org> wrote: > On 07/12/09 23:19, Brian Mathis wrote: >> Not true, and it's the thing that's most irritating about this policy. >> The RPMs are still there, just not the sqlite repodata files that yum >> needs. So if you got to a mirror, you can see all of the files, but >> yum doesn't work. > > well, Brian - you seem to be looking in the wrong place, also you are > mistaken about requirements for sqlite data. So, here is where it stands: > > 5.3 has not been moved to vault.c.o as yet, due to disk space issues, we > should have that resolved in the next few weeks. Once its moved, it will > exist there for as long as we are able to keep it ( we still have all of > 2.1 / 3.* / 4.* and 5.* so far ) > > all metadata for 5.3 is still available in the right place. eg: > http://mirror.centos.org/centos/5.3/updates/i386/repodata/ > http://mirror.centos.org/centos/5.3/os/i386/repodata/ > > Every release ever done by CentOS stays public, and we make every effort > to keep atleast the binary and source files available ( so this > best-effort-warranty does not extend to debuginfo pkgs ). > > hth > > - KB Yes, you are right and I was mistaken. I had performed a server install the other day and yum was having issues getting updates because of missing sqlite files. Apparently this was related to something else, as I performed another install today that was able to apply 5.3 updates just fine. However, the situation does highlight one of the other irritating aspects of the discussion, which is that whenever the topic of holding back a system to an older release comes up, it results in a pigpile of snarky comments about how wrong I am to want to hold back, as if everyone else knows how to manage my environment better than I do. I'm not saying that's what happened here, but that approach quickly discourages any discussion along those lines, and any resolution of the underlying problem is missed. The problem highlighted by the OP, and the issue with VMware Server are both very good examples why one might want to hold back updates. In an enterprise environment, it's perfectly reasonable to want to apply updates to the current version but not upgrade to the next, and reducing the hostility towards this sort of discussion would go a long way in fostering community relationships.