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

even though seems to be a serious bug:-(
btw. not supported but working most of the cases.

Why is this a bug? Afaik an epoch of 10 (the C5 rpm) trumps an epoch of
0 (the C6 rpm). 10 > 0 so do not upgrade.

Regards,
Patrick

and that's the problem...

Let's see:
unsupported method upstream, right?

It did not irk you enough to file a bug, right?

Fix is trivial, right?

Please -- grow up and stop spreading FUD here. The reset away
of the Epoch is a 'Good Thing' (TM) and it only bites those
using a unsupported path

If you feel strongly, edit the wiki release notes, and be done
with it, Farkas

-- Russ herrold

unsupported method upstream, right.
working in upstream, right.
working in centos, not.
the centos is compatible with upstream? no.
is it a bug? yes.
so it is a fud? no it was simple a bug report.

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 :)

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.
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 ? )


- KB

[1]: please do correct me if that seems unreasonable.

http://bugs.centos.org/view.php?idI53

i've reported it under Product Version 5.6 because there is no 6.0
option, maybe 6.0 is intended to have no bugs ;-)

br
ul

actually centos-release is a component in bug.c.o for version 6.0, too.
It's right between celt051 and certmonger.

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).
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:-)
agree the original bug was the introduction of epoc in 5.x.
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?

What happened with the
"aims to be 100% binary compatible"
goal of centos ?

-- Kind Regards, Markus Falb

I am not 100% sure but I'd say we are hit by a side effect of the fact
that centos-release.el5 has epoch = 10 while redhat-release in rhel 5
has none.

not in play ... upstream does not place an offering in the
package namespace of 'centos-release' for obvious reasons

-- Russ herrold