On Sun, 18 Jan 2004, Philip Rowlands wrote: > Hello list, Hi Phil, > This email is long, and reaches no firm conclusion. Skip it now, if you > like :) Most do not. :-) > RedHat Enterprise Linux 3 Update 1 (hereafter RHEL3U1) was released on > Tuesday, with the following note: > > Red Hat Enterprise Linux 3 Update 1 includes a new subdirectory of the > RedHat directory present on CD-ROM #1. This subdirectory, named Updates, > contains all packages that have been added or updated during a quarterly > update. Anaconda has also been modified to search the Updates > subdirectory during installations and upgrades. > > This appears to be structured in such a way that all Update releases to > RHEL3 will modify only the first binary CD image. Disks 2,3,4 remain > unchanged (inferred from MD5 checksums). This was stated on the taroon list to be true. Makes perfect sense to me. You only have to respin and distribute 1 iso. I am sure it also cuts down on QA. > RHEL3U1 CD1 looks like this: > 530 /mnt/cdrom/RedHat/RPMS/amanda-server-2.4.4p1-0.3E.i386.rpm > 75 /mnt/cdrom/RedHat/RPMS/anaconda-product-3-1ES.noarch.rpm > 83 /mnt/cdrom/RedHat/RPMS/arptables_jf-0.0.5-0.3E.i386.rpm > 888 /mnt/cdrom/RedHat/RPMS/freeradius-0.9.0-2.i386.rpm > [...etc.] > 455 /mnt/cdrom/RedHat/Updates/anaconda-runtime-9.1.1-7.RHEL.i386.rpm > 3047 /mnt/cdrom/RedHat/Updates/anaconda-9.1.1-7.RHEL.i386.rpm > 3030 /mnt/cdrom/RedHat/Updates/ant-1.5.2-23.i386.rpm > 908 /mnt/cdrom/RedHat/Updates/freeradius-0.9.3-1.i386.rpm > [...etc.] > > So, RedHat/Updates trumps any existing .rpm files in RedHat. What to do > when one is in the habit of prepatching and running genhdlist at every > opportunity? I do not see the problem in this. In fact I think it is quite clever. IOW I like it!! :-) > I have to conclude that such prepatching will no longer be desirable. If Unless I am missing something I do not think they ever supported this. > RedHat bundle their SRPMS releases for RHEL3 into quarterly updates > (which they did), there's not even the opportunity to be ahead of the > curve w.r.t maintenance upgrades. I assume security fixes would not > rely on this update mechanism as their only release channel. They are only promising quarterly updates. Security updates are being handled separately. AFAIK Red Hat's position is that you get a minimal system up and running and then do all updates etc. during firstboot with up2date. > In theory though, if I did have a new binary RPM which I wanted to munge > into the distribution tree, where to put it? If running genhdlist at > all, it's probably neater to fold Updates into RedHat/RPMS. That keeps > the storage requires down on the kickstart server. Disk is cheap and besides we are only talking 311 Megs. Not the end of the earth as far as disk space is concerned now days. From a customer's standpoint I like it because it makes things easy. The downside is that next quarter they are likely to exceed the capacity of the cd, so they will need to add another one or do something different. I am sure there is a plan though. If you are still going through the pain of maintaining genhdlist why not nuke the updates directory and merge the updated rpms into the RPMS directory? Personally I do not see the need for this. IMO the hassles involved in this FAR outweigh any benefits gained. There are much better ways to update these systems automagically, even if you do not have access to up2date. Just for the record I kickstart every machine I build and by the time the machine gets booted for the first time all of the updates are installed. In addition I have never run genhdlist or done any modifications to anaconda or the cd's. IMO this cuts way down on my maintenance. :-) HTH, Tom
