[CentOS] [CentOS-announce] Release for CentOS-5.7 i386 and x86_64

[Karanbir Singh]

On 09/14/2011 06:59 AM, James A. Peltier wrote:
> Yes, I did notice that, just wondered why.  It seems more prone to breakage (creating multiple symlinks vs one)

There are a couple of reasons. I wont go into all, but the 2 that stick
out the most for me are:

1) symlinking a step deeper means we can have more finer grained control
over the content exported from the <release>/ and the <release>/<repo>
level, specially when it involved shared content ( Extras as one
functional example, addons and contribs as another - but non impacted here )

2) This is the more important one : with /6/ and 6.X/ being real
physical locations there is still the door open that allows /6/ to
become the CR repo. Entirely, across the OS/ and Updates/+ CR/ whereas
6.X/cr/ then becomes local to what is representative of a next-release
content repo ( in relation to the point release its injected into ).
This becomes even more relevant when you factor in 'CR/ content will not
move to vault.c.o when the <release>.X content does'. Furthermore, this
is an important issue when we consider that the CR repo is opt-in,
having a /6/ stream that is always updated and always just-usable
irrespective of what 6.X one installs on their machines is always going
to be a good goal to achieve, imho. Impact on how we do things, how we
store stuff, stage content, get it into the mirrors, export to users and
yum clients : massive. Ofcourse, the only experience that needs to be
protected is the yum-client interface, and can we achieve this refactor
without impacting yum-client interfaces ? I dont know. What I do know,
is that very very few external mirrors have the capacity to handle
something of this nature. Solve'able problems no doubt.

There are also site-specific benefits like being able to add and track
local repo's without needing to add in hackery over the centos mirror
rsync exported content within a <release>/ or <release>.X/ tree. And for
people who run multiple machines, or need to have different production
environments this tends to be quite a big deal.

>From the user perspective, it should not make a difference as to where
the symlinks are setup to -> from. If there is an impact, do tell.

- KB