if it's depchecking what you are looking for; repoclosure is your friend! best, oliver On 04/07/2010 12:41 PM, Angus Clarke wrote: > Hi all > > > > I am tasked with setting up a yum repository server to handle multiple > releases of RedHat Enterprise clients (RHEL3, RHEL4, RHEL5 etc) and for > multiple architectures (well, just i386 and x86_64) > > > > We do not want to offer the entire distribution tree to clients, instead > offering a subset of RPMS. > > I am happy creating repositories from the installation CDs for each > release and architecture; however my issue arises when considering > management of the associated update repositories. On the yum webserver, > we are looking at some directory tree like: > > > > /var/www/html/repos/ <top level> > > > > …3/i386/os > > …3/i386/updates > > …3/x64/os > > …3/x64/updates > > > > …4/i386/os > > …4/i386/updates > > …4/x64/os > > …4/x64/updates > > > > …5/i386/os > > …5/i386/updates > > …5/x64/os > > …5/x64/updates > > > > We only update certain packages, indeed blanket package updates are out > of the question for us. > > > > I envisage us dropping an updated RPM (for example open-ssl) into the > update repos and then running some command to check the update repo > integrity. Is there any elegant way of checking for issues - > specifically RPM dependency issues? Remember that the update repos will > likely be for a different RedHat release and architecture than that of > the webserver it is all running on. > > > > Any pointers gladly received > > ~A > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any actions > taken on the basis of this email are at the recipient's own risk. > > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxx > http://lists.baseurl.org/mailman/listinfo/yum _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
