Re: Managing multiple architecture yum update repositories

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
> [email protected]
> http://lists.baseurl.org/mailman/listinfo/yum

_______________________________________________
Yum mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum