[CentOS-devel] Release farkage potential

[ sorry for the late reply, catching up with e-mail after holiday ]

On Sat, 8 Sep 2007, Karanbir Singh wrote:

> the issue here is that if VAR Mr.$X only supports a product on 5.3.1 
> and CentOS does not provide that, there is a problem. The landscape 
> is littered with people / vendors / support people only recommending 
> people stick within a specific release Update version

IMHO, this comes specifically from the fact that upstream doesn't only 
provide fixes (including security ones) but also functional 
improvements, such that ISVs fear that future updates can influence 
the functionality of their products. So upstream has decided to make 
it clear which updates are considered "safe" and which could 
potentially bring incompatibilities. F.e. for a scientific program 
that only does computation and doesn't use any graphical libraries, a 
security fix for 'kdelibs' coming in 5.0.2 would be sure to not break 
the program which worked on 5.0.0 and 5.0.1, therefore the ISV could 
certify the program for the whole 5.0.x series; OTOH, a new kernel 
coming in 5.1.0 could potentially change some memory map layout (not 
important for the great majority of software out there) and break the 
program (which was badly written in the first place, but the customer 
doesn't know this ;-)), therefore the specific software version would 
loose its certification for 5.1.x.

So the way I interpret this: there are not going to be n+1 different 
distributions released at n-th update step (5.0.2, 5.1.1 and 5.2.0 at 
update step 2, following 5.0.1 and 5.1.0 at update step 1), but n+1 
different distributions in total after n-th step (5.0.2 will replace 
5.0.1 which replaced 5.0.0, 5.1.1 will replace 5.1.0, 5.2.0 is the new 
kid on the block). It's a very similar way of thinking now of versions 
3 and 4 with updates, but without the potential breakage associated 
with those updates.

As such, I believe that there's not going to be any need of 
maintaining a CentOS 5.0.1 forever, but this is going to be replaced 
by 5.0.2, just as now 3.8 is replaced by 3.9; it's going to be needed 
however to keep 5.0.x and 5.1.y (and so on) as separate distributions 
just as now 3 and 4 are kept. But between 5.0.x and 5.1.y there is 
still a large chance of identical packages (as upstream doesn't like 
to rebuild packages that work even if, or especially if, the compiler 
set changes) which should also translate into identical CentOS 
packages. Those could very well be handled by hard links, just like 
today. Some packages will certainly drift over time and will therefore 
require extra space, but I don't believe that it's going to be such an 
explosive growth as expressed here earlier. And there's going to be 
needed a 5.0 soft link pointing to the latest 5.0.x release, a 5.1 
soft link pointing to the latest 5.1.y release and so on.

The only problem that I can see is the storage of the ISO images; 
there's very probably going to be a need for storage of the latest 5.0 
image, latest 5.1 image, etc. just like now the latest 3 (3.9) and 4 
(4.5) images are stored. And, well, those images need to first be 
created, so there's going to be a need to create n+1 images at update 
step n. More work for the CentOS devs :-)

Note: The thoughts expressed above come only from interpreting public 
information; I have no connection to Red Hat.

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu at IWR.Uni-Heidelberg.De