Hi Jeremy: > I know that the updates should be compatible, but it doesn't > always work > out, so we need to plan for update-specific package RPMs.
I don't have a good answer for this - if we are to have separate distro directories for each update, then our repository will indeed be very bloated. I have yet seen an instance where RPMs compiled on a particular update version not work on all (though I think DongInn has eluded to an issue with RHEL4 gold). Anyways at this point I'd say not worry about it unless we have concrete evidence. Perhaps generic-setup can be extended such that if an update directory do show up that they be treated accordingly, eg. if rhel4u1-i386/ and rhel4-i386/ both exists, then the more specific directory takes precedence. > The other reason is that it would be nice to store all of the > installation RPMs on a central server and just NFS mount the directory > from the head node. Since RHEL4U2 and RHEL4U3 require different > subdirectories, then why should the nomenclature for packages differ > from that used for the tftpboot subdirectory? Are you asking why distro/ directories are different from the ones from /tftpboot/distro/ ? Eg. packages/lam/distro/rhel4-x86_64 vs /tftpboot/distro/redhat-el-ws-4-x86_64 Good question, I'll let Erich answer :-) > I was just alluding to OSCAR 5 plans for SUSE support. My mistake--the > correct architecture code is i386 and not ia32. The folks at Seneca are working on it, perhaps you can give them some support ;-) Anyways, during the call today, we discussed about similar issues. Basically both Erich and I agreed that it would be A Good Thing (tm) to make sure that each package has a specific directory for distro/ as I outlined in my original email in this thread, meaning: packages/openmpi/fc5-i386 This will be the _only_ allowed naming convention (perhaps generic-setup should be modified so that everything else will break so that we can much easily fix this). So things like: packages/openmpi/fc5 packages/openmpi/fc-i386 packages/openmpi/fc will no longer be supported. This will allow us to create distro-specific OSCAR distribution tarballs which folks have asked for a while now, and Erich has signed on to modify the tarball building script to support this. Comments? Cheers, Bernard ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
