Hey,
A "powered by RedHat" gif recently appeared on the bottom of the mirror monitor (mirmon) page:
http://www.advanced-app.com.hk/caosity/
This appeared in place of the "powered by CentOS" gif that used to be there.
The mirmon page is getting it from the icons directory under the default html directory.
An Apache update in November put the new gif there in place of the CentOS gif. This was fixed in a httpd update early this month.
This server is on a 28 day update lag. Just a few hours ago, yum automatically updated httpd to version
httpd-0-2.0.46-44.ent.centos.1.i386.hdr
which came into my master repository on November 19th HKT.
Actually, a newer httpd version came in on December 3rd,
httpd-0-2.0.46-44.ent.centos.2.i386.hdr
Theoretically, the appearance of the more recent version should have blocked the installation of the prior version, but the logic in the lag mirror software needs refinement (it is not expecting a newer version to have a non-contiguous number component).
I am away from the office. Could someone please let me know where I can grab the correct gif off some web site?
Thanks,
Rick
On Fri, 17 Dec 2004, Rick Graves wrote:
An Apache update in November put the new gif there in place of the CentOS gif. This was fixed in a httpd update early this month.
This server is on a 28 day update lag. Just a few hours ago, yum automatically updated httpd to version
Theoretically, the appearance of the more recent version should have blocked the installation of the prior version, but the logic in the lag mirror software needs refinement (it is not expecting a newer version to have a non-contiguous number component).
'non-contiguous number component' ????
1->2 is hardly non-contiguous
m-e-v-r comparison should have picked that up ...
Regards Lance
Lance,
'non-contiguous number component' ????
Compare:
httpd-2.0.46-44.ent.centos.1.i386.rpm httpd-2.0.46-44.ent.centos.2.i386.rpm
By "non-contiguous", I meant that the "1" and "2" digits are separated from the main version number, 2.0.46-44.
But having quickly checked the code, I am wondering why the code made the mistake of putting httpd-2.0.46-44.ent.centos.1.i386.rpm in the 28 day lag directory. (I will have to investigate more.)
m-e-v-r comparison should have picked that up ...
What is a m-e-v-r comparison? Please tell me more.
Thanks,
Rick
--- Lance Davis lance@uklinux.net wrote:
On Fri, 17 Dec 2004, Rick Graves wrote:
An Apache update in November put the new gif there
in
place of the CentOS gif. This was fixed in a
httpd
update early this month.
This server is on a 28 day update lag. Just a few hours ago, yum automatically updated httpd to
version
Theoretically, the appearance of the more recent version should have blocked the installation of
the
prior version, but the logic in the lag mirror software needs refinement (it is not expecting a
newer
version to have a non-contiguous number
component).
'non-contiguous number component' ????
1->2 is hardly non-contiguous
m-e-v-r comparison should have picked that up ...
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
On Sat, 18 Dec 2004, Rick Graves wrote:
Lance,
'non-contiguous number component' ????
Compare:
httpd-2.0.46-44.ent.centos.1.i386.rpm httpd-2.0.46-44.ent.centos.2.i386.rpm
By "non-contiguous", I meant that the "1" and "2" digits are separated from the main version number, 2.0.46-44.
but ent.centos.2 is the release number and is alphabetically later than ent.centos.1
But having quickly checked the code, I am wondering why the code made the mistake of putting httpd-2.0.46-44.ent.centos.1.i386.rpm in the 28 day lag directory. (I will have to investigate more.)
m-e-v-r comparison should have picked that up ...
What is a m-e-v-r comparison? Please tell me more.
sorry - n
name - epoch - version - release
the way rpm works
Regards Lance
Thanks,
Rick
--- Lance Davis lance@uklinux.net wrote:
On Fri, 17 Dec 2004, Rick Graves wrote:
An Apache update in November put the new gif there
in
place of the CentOS gif. This was fixed in a
httpd
update early this month.
This server is on a 28 day update lag. Just a few hours ago, yum automatically updated httpd to
version
Theoretically, the appearance of the more recent version should have blocked the installation of
the
prior version, but the logic in the lag mirror software needs refinement (it is not expecting a
newer
version to have a non-contiguous number
component).
'non-contiguous number component' ????
1->2 is hardly non-contiguous
m-e-v-r comparison should have picked that up ...
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Saturday, 18 December 2004, at 06:26:26 (-0800), Rick Graves wrote:
Compare:
httpd-2.0.46-44.ent.centos.1.i386.rpm httpd-2.0.46-44.ent.centos.2.i386.rpm
By "non-contiguous", I meant that the "1" and "2" digits are separated from the main version number, 2.0.46-44.
The version number is actually "2.0.46," and the release is "44.ent.centos.1". If your code isn't catching that, it's not doing the comparison right.
I have some perl code and some C code that does pretty reliable version comparisons, in some cases better than rpm does. Let me know if you're interested. But the basic idea is to split the version and release into numeric and non-numeric portions and compare each one in turn. It's not a straight string compare; if it were, 2.0.46 would seem to be a higher version than 2.0.127. Numbers are compared numerically for that reason. So the comparison becomes this:
2 . 0 . 46 44 .ent.centos. 1 2 . 0 . 46 44 .ent.centos. 2
Clearly, 1 < 2, so the latter is the newer package.
HTH, Michael
On Mon, 2004-12-20 at 02:17 -0500, Michael Jennings wrote:
On Saturday, 18 December 2004, at 06:26:26 (-0800), Rick Graves wrote:
Compare:
httpd-2.0.46-44.ent.centos.1.i386.rpm httpd-2.0.46-44.ent.centos.2.i386.rpm
By "non-contiguous", I meant that the "1" and "2" digits are separated from the main version number, 2.0.46-44.
The version number is actually "2.0.46," and the release is "44.ent.centos.1". If your code isn't catching that, it's not doing the comparison right.
I have some perl code and some C code that does pretty reliable version comparisons, in some cases better than rpm does.
How can it do it better than rpm? Either it's the same as rpm or it's wrong.
any other version comparison result is incorrect.
Let me know if you're interested. But the basic idea is to split the version and release into numeric and non-numeric portions and compare each one in turn. It's not a straight string compare; if it were, 2.0.46 would seem to be a higher version than 2.0.127. Numbers are compared numerically for that reason. So the comparison becomes this:
2 . 0 . 46 44 .ent.centos. 1 2 . 0 . 46 44 .ent.centos. 2
Clearly, 1 < 2, so the latter is the newer package.
just use the python modules. They link in directly to the rpmlib and use its version comparison functions.
-sv
On Monday, 20 December 2004, at 02:21:56 (-0500), seth vidal wrote:
How can it do it better than rpm? Either it's the same as rpm or it's wrong.
any other version comparison result is incorrect.
For rpm, sure. But for general comparison of version strings, it gets some right that rpm gets wrong. (For example, it knows 2.5.4p1 > 2.5.4 while 2.5.4beta7 < 2.5.4.)
just use the python modules. They link in directly to the rpmlib and use its version comparison functions.
Using the appropriate rpmlib bindings for whatever language one is using is always the most accurate approach. But if one chooses to not do so, it's good to understand the principles behind how the comparison works.
Michael
On Mon, 2004-12-20 at 03:41 -0500, Michael Jennings wrote:
On Monday, 20 December 2004, at 02:21:56 (-0500), seth vidal wrote:
How can it do it better than rpm? Either it's the same as rpm or it's wrong.
any other version comparison result is incorrect.
For rpm, sure. But for general comparison of version strings, it gets some right that rpm gets wrong. (For example, it knows 2.5.4p1 > 2.5.4 while 2.5.4beta7 < 2.5.4.)
except that it's not accurate.
a < 1 z < 0
any number is ALWAYS greater than any letter when doing token comparison.
so saying that 2.5.4p1 > 2.5.4 while 2.5.4beta7 < 2.5.4 is just not accurate.
it depends entirely on the program.
I can think of many situations where 2.5.4beta7 may well be > 2.5.4
It just depends on what kind of special crack the person choosing the versioning is on.
just use the python modules. They link in directly to the rpmlib and use its version comparison functions.
Using the appropriate rpmlib bindings for whatever language one is using is always the most accurate approach. But if one chooses to not do so, it's good to understand the principles behind how the comparison works.
Sure - it's useful to understand the principles. Unfortunately the principles break down to be something like this: - rpm is right - if it's not the same as what rpm claims it is for version comparison, it's wrong. - if rpm gets changed to reflect the behavior you want, then that behavior becomes right. Up until that point it is wrong.
rpm is canonical and definitive in this situation. If you do otherwise you'll end up zigging when you should have zagged.
-sv
Michael,
Clearly, 1 < 2, so the latter is the newer package.
Thanks, I am clear on that. My code was sometimes not working right. I simplified and clarified it, and it is working right now -- at least on the httpd versions, and I hope on everything else.
It's not a straight string compare; if it were, 2.0.46 would seem to be a higher version than 2.0.127.
Thanks for the heads up on this point. My code is not this sophisticated.
I am not sure I need to even worry about comparisons on this level. My program is most concerned about when a *different* version appears on the public mirrors. So 2.0.46 would be different than 2.0.127, and my logic presumes the one that appears after supercedes the one that appeared before.
At this point, I have not yet tackled removing obsolete versions. I leave it up to yum to decide which is "newer" for its purposes. Basically, my plan was to remove a version after it disappears from the public mirrors, and after it has been superceded by something that appeared later.
Thanks for bringing up the point about 2.0.46 vs. 2.0.127; I will want to keep this in mind going foward.
Rick
--- Michael Jennings mej@caosity.org wrote:
On Saturday, 18 December 2004, at 06:26:26 (-0800), Rick Graves wrote:
Compare:
httpd-2.0.46-44.ent.centos.1.i386.rpm httpd-2.0.46-44.ent.centos.2.i386.rpm
By "non-contiguous", I meant that the "1" and "2"
digits are
separated from the main version number, 2.0.46-44.
The version number is actually "2.0.46," and the release is "44.ent.centos.1". If your code isn't catching that, it's not doing the comparison right.
I have some perl code and some C code that does pretty reliable version comparisons, in some cases better than rpm does. Let me know if you're interested. But the basic idea is to split the version and release into numeric and non-numeric portions and compare each one in turn. It's not a straight string compare; if it were, 2.0.46 would seem to be a higher version than 2.0.127. Numbers are compared numerically for that reason. So the comparison becomes this:
2 . 0 . 46 44 .ent.centos. 1 2 . 0 . 46 44 .ent.centos. 2
Clearly, 1 < 2, so the latter is the newer package.
HTH, Michael
-- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ mej@kainx.org n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"She'd still say, 'I love you' if I asked, but she never volunteers. Somehow what she never says means more than all the other words I hear." -- BlackHawk, "I Sure Can Smell the Rain"
On Monday, 20 December 2004, at 09:18:48 (-0800), Rick Graves wrote:
Thanks, I am clear on that. My code was sometimes not working right. I simplified and clarified it, and it is working right now -- at least on the httpd versions, and I hope on everything else.
Is your code Python? If so, you should use the python rpmlib bindings for this.
I am not sure I need to even worry about comparisons on this level. My program is most concerned about when a *different* version appears on the public mirrors. So 2.0.46 would be different than 2.0.127, and my logic presumes the one that appears after supercedes the one that appeared before.
Yeah, that's how mine worked too, only it used version comparison to handle the case where multiple new updates for the same package appeared simultaneously (which can happen if the script doesn't run frequently enough or a quickie-fix is required.
Michael
On Fri, 17 Dec 2004, Rick Graves wrote:
I am away from the office. Could someone please let me know where I can grab the correct gif off some web site?
Download the new rpm and install it.
Or download the src.rpm, unpackk it and copy the image file.
Lance
anyway - isnt this the idea of lagmirror - to give you n days extra exposure to security flaws and bugs ;)
Lance,
Download the new rpm and install it.
If anyone is displaying the "powered by CentOS" gif, it would be easier for me just to grab it and put it in the icons directory under the main http directory.
Come on, isn't anyone on the planet displaying the "powered by CentOS" gif? Please speak up!
anyway - isnt this the idea of lagmirror - to give you n days extra exposure to security flaws and bugs ;)
Almost. The idea is for the program to block security flaws and bugs ATUOMATICALLY.
I do not think the wrong gif would be considered a security flaw. Bug maybe.
The program should have blocked the httpd version with the wrong gif. I am investigating.
Rick
--- Lance Davis lance@uklinux.net wrote:
On Fri, 17 Dec 2004, Rick Graves wrote:
I am away from the office. Could someone please
let
me know where I can grab the correct gif off some
web
site?
Download the new rpm and install it.
Or download the src.rpm, unpackk it and copy the image file.
Lance
anyway - isnt this the idea of lagmirror - to give you n days extra exposure to security flaws and bugs ;)
-- uklinux.net - The ISP of choice for the discerning Linux user.
On Sat, 2004-12-18 at 07:01 -0800, Rick Graves wrote:
Lance,
Download the new rpm and install it.
If anyone is displaying the "powered by CentOS" gif, it would be easier for me just to grab it and put it in the icons directory under the main http directory.
Come on, isn't anyone on the planet displaying the "powered by CentOS" gif? Please speak up!
On Sat, 2004-12-18 at 07:01 -0800, Rick Graves wrote:
Come on, isn't anyone on the planet displaying the "powered by CentOS" gif? Please speak up!
And you made me feel guilty, so I also put the gif on my main site:
:)
-
Johnny Hughes -
Lance Davis -
Michael Jennings -
Rick Graves -
seth vidal