On Mon, 13 Jun 2011, Levend Sayar wrote:
> We have a continuous integration machine that builds
> everyday. Instead of downloading same packages from centos
> each day, we copy 5.5 rpms on a local web server and build
> uses that server. In fact, this is one of the alternatives
> that build system supplies.
unless you are pulling from a mirror of the /5/ part of the
tree (i.e., by having pulled from a /5.point/ image) you
guarantee that you will 'fall behind' when a new CentOS
release issues. All the ".point" (here, where .point == .5)
means is a re-spin in time base, and new set of updates from
on the '5' tree'.
CentOS' upstream has a concept of a longer lived, fixed point
release channel, with a 24 month life, overall, called a 'z'
channel, but this is not well defined from an engineering
point of view, and not suseptible to replication that yields
much utility ...
> By doing this, I did not notice that we are using a snapshot
> of centos in the first place. Do they update 5.5 branch when
> they make any enhancements ? I suppose that they freeze as
> is in a branch. Do they change the content under 5.5 for
> example ?
'they' do NOT 'freeze' as in a branch, but rather track the
upstream as updates of various color and stripe -- some
security related, some functionality enhancements, and some
simply to satisfy dependencies for the prior two categories
...
> So we are not trying to get a mirror in fact. Just do not
> want to do same downloads each day.
The master you are copying from _should_ mirror, perhaps a
'current' and a 'staging' mirror instance. The delta load is
fairly minimal once the initial 'suck down' is done, and
indeed with hardlinks, without much of a space penalty
see a blog post I wrote some time ago about using 'lftp'
http://orcorc.blogspot.com/2010/08/mirroring-upstream-master-with-lftp-to.html
for mirroring
-- Russ herrold
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
