[CentOS-devel] package centos-release-10:5-6.el5.centos.1.x86_64 newer than centos-release-6-0.el6.centos.5.x86_64

Tue Jul 12 11:14:27 UTC 2011
Farkas Levente <lfarkas at lfarkas.org>

first of all my original mail was write in the same style as russ reply
was made. if you handle every mail in such a style the don't expect
different reply.
anyway it seems you (karanbir) change your style and reply as a/all
'user' can expect what's more in style which has useful information (so
it not just a spam to the list).

On 07/11/2011 05:51 PM, Karanbir Singh wrote:
> On 07/11/2011 09:26 AM, Farkas Levente wrote:
>> unsupported method upstream, right.
>> working in upstream, right.
>> working in centos, not.
> 
> I disagree. Let me explain why that is : RHEL and CentOS address very 
> different userbases. Looking through the sort of posts that make it to 
> the different mailing lists would make this quite clear. RHEL will work 
> through support stuff with people, its not that simple on CentOS.
> 
> When you say this 'it works upstream', you are changing the definition 
> of what 'it' might be in comparision to what the definition of 'it' is 
> in regards to CentOS. To me, 'it' amounts to being able to upgrade from 
> C5 to C6 or EL5 to EL6, without a wipe+reinstall[1]. And 'it' works in 
> just about exactly the same way on CentOS as on RHEL - you need to 
> custom build rpm, its dep chain. then get py26 in place, with yum that 
> uses that py26 ( on c5 ), then go through 2 reboot cycles in order to 
> make the process work. At the second boot stage, you need the 
> centos-release rpm to be replaced. Also important at this stage is that 
> having a $releasever at '5' does not break your machine, so a manual 
> choice being needed to come into effect for $releasecer to move to '6' 
> isnt a bad thing, I'd even venture a bit closer to the edge and say its 
> a 'feature'.
> 
> the fact that it breaks the upgradeany install isnt ideal. Its not a 
> 'supported' mechanism, but then not much is 'supported' within the 
> centos ecosystem either; and having the flexibility to break your stuff 
> in ways you find interesting is also a feature in CentOS :)

to define the 'it': what i mean is that from rhel-5.6 to rhel-6.0 the
upgrade is possible. the upgrade do not by definition means "yum update"
what's more imho it's a bad habit to use python code as system command
(even though i'm alos lazy). of course it would be the best if a simple
yum update/upgrade can be working.
but still with upgradeany and rpm itself (in a few step, glibc, rpm
etc.) the upgrade is possible. in most case the reinstall not so simple
and eg in larger server farm with a few hundreds of server it's even
better to create some kind of update mechanism. test it on a few server
and after run on a few hundreds then reinstall them.
so if something is possible with rhel which is not possible with centos
is a bug (of course rpm -Uvh --force can always work:-)

> I agree with Russ on that lets document this for now, and try to see how 
> we can resolve the case moving forward ( 6.1 isnt far! ); exactly what 
> the fix might be is still open to debate a bit. Reintroducting an EPOC 
> should, please please, be the last resort.

agree the original bug was the introduction of epoc in 5.x.

>> the centos is compatible with upstream? no.
>> is it a bug? yes.
>> so it is a fud? no it was simple a bug report.
> 
> Did you then file it as a bug report ? And did you either add something 
> to the RNotes in the wiki ( or propose text that should be added in ? )

huuuu. this part sounds funny even from russ and even from you. did you
or any centos developer made publicly available any build problem or
it's solution? afaik i was the only one who write a long mail about it
on centos-devel (and SL people made their problems and solution public
on their website). did you or russ fill any bz on rh's website during
the 6.0 rebuild? i fill a few dozens (almost all).
can we know what did you change during the rebuild?
can we know how did you solve the build problems?
no. simple these are hidden somewhere inside the centos build system.
can you/centos accept any help from anyone outside? did you reply any of
original mails? we all know the reason why was the long email thread by
dag about this issue. i just thought i was useless to get into that.
so after that did you really think that i'm the one who not try to share
my knowledge with the community?

-- 
  Levente                               "Si vis pacem para bellum!"