646247 - set up internal yum repo for build systems

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[John Ford [:jhford] CET/CEST Berlin Time]

Instead of having to add every rpm we deploy to the puppet-manifests, lets keep these files in a yum repository.  I suggest that we have two repositories, one public (mozilla-releng-public) and one private (mozilla-releng-private).  This would make life easier for people outside of moco's build network from keeping their systems close to the official build systems.

Another (imo) practical advantage to using YUM over low level RPM is that we would be able to resolve circular dependencies without having to hack the spec files or do Exec rpm -Uvh depA.rpm depB.rpm in the manifests.  This came up while deploying an updated fontconfig (and was annoying).

In order to keep our systems up to date and make the puppet manfiests simpler, I suggest that create empty meta package that depends on the specific versions of a package.  We can also look at comps.xml + groupinstall, but not sure if that can be made to force specific versions of packages.

In the future, we could also set up our own updates repository mirror so that we can ensure that all of our rpm based machines are able to get the same version of all system packages.  In the far future, we could set up a system to PXE boot and install a linux system from scratch using only our own repositories (to guarantee specific versions)

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

This will be a prerequisite for the new puppet infrastructure, and everything in comment 0 sounds like a great boon (especially workarounds for circular deps!).

What will this require?

Comment 3

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to comment #2)
> What will this require?

I will do the development on my desktop and can post the resulting repository to any http server we have, stage/ftp should work.  Once we decide to go with this, I will likely do this work on the same machine we will use to create our fedora product repository.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

OK - let's loop back on the decision of where to host it when you're at that point.  This sounds great!

Comment 5

[[e-mail] (:bhearsum)]

Are these going to overlap with http://mrepo.mozilla.org/mrepo/?

Comment 7

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to comment #5)
> Are these going to overlap with http://mrepo.mozilla.org/mrepo/?

Aiui, that is a mirror of the upstream repositories used for pxe+ks.  This would be for non-upstream packages that contain our dependencies.

Comment 8

[John Ford [:jhford] CET/CEST Berlin Time]

I have been having issues with mock builds targetting EL6.  It looks like there is a testing version of mock that should include working epel-6 configs

https://bugzilla.redhat.com/show_bug.cgi?id=679885#c19

http://kojipkgs.fedoraproject.org/packages/mock/1.1.12/1.el6/noarch/mock-1.1.12-1.el6.noarch.rpm

Comment 10

[John Ford [:jhford] CET/CEST Berlin Time]

i think we can close this out?  we have centos 6.0, fedora 16 and mozilla internal mirrors set up for puppet again.