[Fedora-packaging] root of a repository

[John Dennis]

On 06/01/2012 12:57 AM, Garrett Holmstrom wrote:
> On 5/28/2012 7:59 AM, Mihamina Rakotomandimby wrote:
>> I have a repository
>>
>> $ tree -d -L 2
>> .
>> └── 16
>> ├── i386
>> └── x86_64
>>
>> i386&  x86_64 both contain their set of rpm.
>>
>> If I want to create a repo (run "yum createrepo"), would you advice me
>> to create it at "16" level or at "i386&  x86_64" level?
>
> It's just ``createrepo''.  Fedora typically runs it at the "i386" and
> "x86_64" level.

As well as partitioning debuginfo and src packages into separate repos 
as well. Also don't forget about special handling of multilib where both 
32-bit and 64-bit packages appear in the same repo.

Emulating how Fedora lays out it's it's repositories given a random set 
of packages is non-trivial. Another common requirement is the need to 
merge in updates to some packages.

I know this is non-trivial because I wrote a Python script to do it for 
a development repository we maintain for FreeIPA. At the time we set 
this up (2 -3 years ago) I couldn't find public tools to do what would 
seem to be useful functionality, so we wrote it ourselves. I don't know 
if the yum tools have evolved in the meantime to support things like 
this but if not we should probably share what we've done.

FWIW, what the script does is this: you point it at a set of URL's 
containing RPM's, it recursively traverses each and builds a set of 
candidate packages. It then compares the candidates to the existing 
destination tree of repos (distribution, arch, src, debuginfo) and 
replaces any package in a destination repo with it's newer candidate and 
adds any candidate not in the destination. The resulting destination 
tree of repos exactly mirrors the Fedora layout. It can also rsync the 
repo tree to a public location and send email about which packages were 
updated. It also integrates with our automated build system which sends 
an AMQP message when a build is complete which then triggers the repo 
building script to run which automatically rebuilds the repos and 
uploads them via rsync to a public location. Thus the public repos 
within minutes of a build completing.

We use this to keep a rolling set of repos for nightly builds for the 
last 3 versions of Fedora as well as RHEL 5 and RHEL 6. Developers just 
install a generic yum repo config file that uses the same substitution 
variables for arch, os, etc. It's worked well for us, running unattended 
for months at a time.




-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/