[Yum] Managing multiple architecture yum update repositories

Angus Clarke angusc at PartyGaming.com
Wed Apr 7 10:41:45 UTC 2010


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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum/attachments/20100407/93fba2e8/attachment.htm>


More information about the Yum mailing list