[CentOS-devel] Release farkage potential
Bogdan Costescu
Bogdan.Costescu at iwr.uni-heidelberg.de
Thu Sep 13 12:54:16 UTC 2007
[ 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
More information about the CentOS-devel
mailing list