We currently have a need for releng generated rpms. Currently, there is only one repository for all releng generated rpms. Instead of using one repository that has the rpms for both distributions and all archs in one repository, we should have a releng-public repository for each combination of distribution and release. we should move from having one repository http://$config::yum_server/repos/yum/releng/public/noarch to having something like: http://$config::yum_server/repos/yum/releng/public/CentOS/6/i386 http://$config::yum_server/repos/yum/releng/public/CentOS/6/x86_64 http://$config::yum_server/repos/yum/releng/public/Fedora/16/i386 http://$config::yum_server/repos/yum/releng/public/Fedora/16/x86_64 Because these RPMs are written by us, I think we should make an SRPM repository available, as a lower priority. We'll need to figure out how to get releng generated rpms into this repository.

(In reply to John Ford [:jhford] from comment #0) > Because these RPMs are written by us, I think we should make an SRPM > repository available, as a lower priority. Since some of the packages are distributed under terms of (L)GPL or similar licenses, once we start distributing compiled packages, we'll have to distribute the sources (SRPMs) as well to avoid license violations.

(In reply to Rail Aliiev [:rail] from comment #1) > (In reply to John Ford [:jhford] from comment #0) > > Because these RPMs are written by us, I think we should make an SRPM > > repository available, as a lower priority. > > Since some of the packages are distributed under terms of (L)GPL or similar > licenses, once we start distributing compiled packages, we'll have to > distribute the sources (SRPMs) as well to avoid license violations. Yep, for now these are internal repos, but having them world-readable is definitely something we want!

Turns out that if we build the repository with the srpms and debuginfo packages inside, doing |yumdownloader --source| and |debuginfo-install| both work for our packages

The existing repo has been commented out because it's cause many problems

Is there a particular reason not to just put all of the distro/arch packages in the same repo? I've no problem with this, except that it's more repos to juggle, but I'm curious why. (In reply to John Ford [:jhford] from comment #3) > Turns out that if we build the repository with the srpms and debuginfo > packages inside, doing |yumdownloader --source| and |debuginfo-install| both > work for our packages Does this mean that we don't need separate SRPMs directories? (In reply to John Ford [:jhford] from comment #4) > The existing repo has been commented out because it's cause many problems Can you elaborate, or point to bugs?

(In reply to Dustin J. Mitchell [:dustin] from comment #5) > Is there a particular reason not to just put all of the distro/arch packages > in the same repo? I've no problem with this, except that it's more repos to > juggle, but I'm curious why. We currently run centos6.2 and are using fedora16, but that doesn't mean we'll only ever use fedora16 and centos6.2. This won't result in any extra repositories at this time because we only have one version per distro-arch. > (In reply to John Ford [:jhford] from comment #3) > > Turns out that if we build the repository with the srpms and debuginfo > > packages inside, doing |yumdownloader --source| and |debuginfo-install| both > > work for our packages > > Does this mean that we don't need separate SRPMs directories? Look like it, yes. > (In reply to John Ford [:jhford] from comment #4) > > The existing repo has been commented out because it's cause many problems > > Can you elaborate, or point to bugs? I re-enabled it. I this repo was broken in mtv1 but works in scl1. It was stopping me from being able land changes and test them post-landingl.

aiui, the only thing that is being managed by puppet is the creation of the directories that hold the repositories. I think this patch does it, but I cannot test that.

Comment on attachment 608117 [details] [diff] [review] create mirrors I'd rather name this 'releng' to differentiate it from the mozilla repos on mrepo.mozilla.org. So, basically, s!/mozilla/!/releng/public/! and remove the resulting duplicate line. What does the comment mean? Are those not authoritative for some reason?

the mock configurations will need updating once we get the URLs for these figured out

(In reply to Dustin J. Mitchell [:dustin] from comment #8) > Comment on attachment 608117 [details] [diff] [review] > create mirrors > > I'd rather name this 'releng' to differentiate it from the mozilla repos on > mrepo.mozilla.org. So, basically, s!/mozilla/!/releng/public/! and remove > the resulting duplicate line. Agreed > What does the comment mean? Are those not authoritative for some reason? I don't know what John meant here. Perhaps that these aren't official centos/fedora repos?

The sysadmins puppet no longer creates directories or does anything under /data other than synchronize it. So there's no actual patch here, and all that remains is to figure out how to migrate this in a compatible fashion, which probably just requires some temporary symlinks and a plan to eliminate them later. So, this can happen while I'm away, although I don't yet trust csync2 well enough to be confident it will sync flawlessly. Or, it can happen now. Catlee, can you put together a patch for hgmo/build/puppet to change the repos and the mock configs appropriately?

Comment on attachment 629807 [details] [diff] [review] add distro specific releng mirrors Review of attachment 629807 [details] [diff] [review]: ----------------------------------------------------------------- I think it would make more sense to construct the paths dynamically based on the OS and version, rather than use conditionals. I do like substituting the puppet factors into the URLs in puppet, so that the .repo files have real URLs in them that I can copy/paste. Also, when did we grow a "Mozilla" repository? I think that's confusing, since we have a "Mozilla" repository on mrepo as well with different contents. That's why I created the "releng" repo. Also, the mozilla repo isn't on https://wiki.mozilla.org/ReleaseEngineering/PuppetAgain/Repositories. And why is there a copy of the puppet RPM in the releng repo? That RPM is in the puppetlabs repo, and isn't a custom RPM anyway. Sorry, this is in much worse shape than I realized this morning.. we should get it cleaned up in this bug.