Hi Johnny et al.,
I'd like to raise a query relating to recent package versioning.
For example, CentOS recently released the following updates:
httpd-2.2.3-45.el5.centos.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
relating to the upstream packages:
httpd-2.2.3-45.el5_6.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
which IMHO is confusing.
In the case of selinux-policy (and others) CentOS rigorously follows the upstream versioning, yet for httpd the versioning is different.
Firstly, IMHO it is difficult to establish that the two (httpd) packages are indeed the same, and secondly, one wonders how CentOS might handle the notional upstream release of httpd-2.2.3-45.el5_7.1.src.rpm, for example.
Where it is necessary to append the centos tag, I would assume it would be preferable to do it at the end of the existing release string thus preserving the upstream notation.
For example,
httpd-2.2.3-45.el5_6.1.centos.src.rpm
I realise it's not easy when upstream do things like this:
Release: 45%{?dist}.1
but at the very least it would be nice if you could set %{dist} to el5_6.centos in this case which would be a closer match to upstream
As it stands, it looks like the centos.1 was appended by CentOS and the original upstream package was httpd-2.2.3-45.el5.src.rpm which clearly isn't the case.
In such cases, would editing the SPEC file release line be the lesser of two evils?
On 05/04/2011 02:35 PM, Ned Slider wrote:
Hi Johnny et al.,
I'd like to raise a query relating to recent package versioning.
For example, CentOS recently released the following updates:
httpd-2.2.3-45.el5.centos.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
relating to the upstream packages:
httpd-2.2.3-45.el5_6.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
which IMHO is confusing.
not really. the .el5_6 is the distag from upstream, for all centos mod packages since 2005 or so we've used the .el<blah>.centos as the disttag. Comes back to the whole argument of what is a disttag and why its there. Upstream uses it to indicate something - we just try and stay consistent with it.
In the case of selinux-policy (and others) CentOS rigorously follows the upstream versioning, yet for httpd the versioning is different.
thats because httpd is a changed package. It also means that the tests against the packages are a bit easier than they would be for something that isnt modified by us.
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
- KB
On 05/04/2011 09:51 AM, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
Hi Johnny et al.,
I'd like to raise a query relating to recent package versioning.
For example, CentOS recently released the following updates:
httpd-2.2.3-45.el5.centos.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
relating to the upstream packages:
httpd-2.2.3-45.el5_6.1.src.rpm selinux-policy-2.4.6-300.el5_6.1.src.rpm
which IMHO is confusing.
not really. the .el5_6 is the distag from upstream, for all centos mod packages since 2005 or so we've used the .el<blah>.centos as the disttag. Comes back to the whole argument of what is a disttag and why its there. Upstream uses it to indicate something - we just try and stay consistent with it.
Would httpd-2.2.3-45.el5_6.centos.1 possibly be more appropriate (albeit long and ugly)? Just for closer matching with upstream for people that are obsessive over such things? Or is the -45 really the main part of the release that anyone would need to focus on (especially in the case of a security update that addresses CVE-2011-xxxx etc etc)?
On 05/04/2011 03:51 PM, David Hollis wrote:
Would httpd-2.2.3-45.el5_6.centos.1 possibly be more appropriate (albeit
not really. Look at it from the point of view of what that el5_6 represents upstream.
also, Ned if you look back at the history of the RHEL platform you will see that the actual tag isnt used in update comparisons.
- KB
On 04/05/11 16:52, Karanbir Singh wrote:
On 05/04/2011 03:51 PM, David Hollis wrote:
Would httpd-2.2.3-45.el5_6.centos.1 possibly be more appropriate (albeit
not really. Look at it from the point of view of what that el5_6 represents upstream.
The issue here is a) it's different from upstream, and b) you're not being consistent as you rebuild some packages with the el5_6 style dist tag but not for others.
also, Ned if you look back at the history of the RHEL platform you will see that the actual tag isnt used in update comparisons.
Maybe, but I'm not sure if that is not more through luck than judgement?
For example, look back at:
httpd-2.2.3-11.el5_1.3.src.rpm
and
httpd-2.2.3-11.el5_2.4.src.rpm
here el5_2.4 > el5_1.3
The current CentOS scheme survives by the fact that .4 > .3 rather than by virtue of the el5_2 > el5_1 portion of the release that takes precedence in the upstream release. Admittedly that is the only such example I can find for the httpd package, and it does date back to 2008.
Is that intentional on the part of upstream? I doubt we'll ever know the answer to that.
On 05/04/2011 06:00 PM, Ned Slider wrote:
The issue here is a) it's different from upstream, and b) you're not being consistent as you rebuild some packages with the el5_6 style dist tag but not for others.
The only place we change that is when its a centos mod package; not otherwise. Changing this policy for CentOS-5 at this stage does not seem like a good idea at all.
httpd-2.2.3-11.el5_1.3.src.rpm httpd-2.2.3-11.el5_2.4.src.rpm
here el5_2.4> el5_1.3
yes, but so was .el5.centos.4 > .el5.centos.3
Is that intentional on the part of upstream? I doubt we'll ever know the answer to that.
it is by design, it is my understanding that the right-of %{dist} only changes within a single point release cycle.
- KB
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 06:00 PM, Ned Slider wrote:
httpd-2.2.3-11.el5_1.3.src.rpm httpd-2.2.3-11.el5_2.4.src.rpm
here el5_2.4> el5_1.3
yes, but so was .el5.centos.4 > .el5.centos.3
I think Ned's point is that .el5_1.3 is not higher than .el5.centos.4 in two hypothetical cases. Either where a package would need a change after an updated package. Or when the %{dist} used to be el5 and becomes el5_2.
So this would only work if it is guaranteed that:
- .centos is always added during the entire lifespan - the version is not different but only %{dist} changes
Is that intentional on the part of upstream? I doubt we'll ever know the answer to that.
it is by design, it is my understanding that the right-of %{dist} only changes within a single point release cycle.
If you assume that Red Hat always changes something in the version string, and not depends on %{dist} changing. I wouldn't be sure of that, but I lack the resources to scan the entire list of RHEL5 SRPMs.
On 05/04/2011 06:54 PM, Dag Wieers wrote:
So this would only work if it is guaranteed that:
- .centos is always added during the entire lifespan
yes, and we should be doing this
- the version is not different but only %{dist} changes
that is irrelevant. The whole point is that the way packages are released upstream the tag component, while present and relevant, isnt considered in the EVR > prev.relese-EVR
- KB
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
It depends on what message you want to send. Obviously Ned is confused by how it is done now, and it makes it hard for people to match upstream packages with CentOS packages.
Despite the technical reasons, if the message is to confuse those users, you are on the right track.
On 05/04/2011 10:45 AM, Dag Wieers wrote:
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
It depends on what message you want to send. Obviously Ned is confused by how it is done now, and it makes it hard for people to match upstream packages with CentOS packages.
Despite the technical reasons, if the message is to confuse those users, you are on the right track.
We have been doing this exactly the same for 8 years.
There is no reason to reinvent the wheel here.
It is very simple ...
1. If we do not change a package, it will have the exact same dist tag as upstream.
2. If we do change a package, then the dist tag will always be .el5.centos.
This is not confusing, and is exactly what we have been doing since we stood up CentOS.
What is confusing about this?
On Wed, 4 May 2011, Johnny Hughes wrote:
On 05/04/2011 10:45 AM, Dag Wieers wrote:
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
It depends on what message you want to send. Obviously Ned is confused by how it is done now, and it makes it hard for people to match upstream packages with CentOS packages.
Despite the technical reasons, if the message is to confuse those users, you are on the right track.
We have been doing this exactly the same for 8 years.
Since 8 years ago some things have changed. 8 years ago there was no %{dist} tag. When there was a disttag, it used to be a fixed tag (eg. .el5), not el5_2.
There is no reason to reinvent the wheel here.
It is very simple ...
- If we do not change a package, it will have the exact same dist tag
as upstream.
So a %{dist} with .el5_2 stays .el5_2 on CentOS. No problem there.
- If we do change a package, then the dist tag will always be .el5.centos.
So a %{dist} with .el5_2.4 becomes .el5.centos.4, and there is no visual indication that both packages are related. Whereas .el5_2.centos.4 or .el5_2.4.centos would have been a more appropriate, and more correct (wrt. to depsolving) solution.
In the above example you may have noticed that .el5_2.4 > .el5.centos.4, while .el5 < .el5.centos
This is not confusing, and is exactly what we have been doing since we stood up CentOS.
With the difference that things have changed in the meantime which makes it confusing that httpd-2.2.3-45.el5_6.1.src.rpm on RHEL5 becomes httpd-2.2.3-45.el5.centos.1.src.rpm on CentOS5.
What is confusing about this?
What is most confusing is that you do not appear to acknowledge what has been reported. I am not saying this is a grave problem, but you are ignoring the issue completely, as if Ned or me, or anyone else is wrong to even bring it up.
It reminds me a lot like the debate about the delay of CentOS 5.6. Nobody acknowledged that the delay has becoming longer the past years, nobody acknowledged that this is something the project is interested to improve, the messenger is wrong, the project is right. Discussion closed.
Le 05/05/11 11:59, Dag Wieers a écrit :
On Wed, 4 May 2011, Johnny Hughes wrote:
On 05/04/2011 10:45 AM, Dag Wieers wrote:
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
It depends on what message you want to send. Obviously Ned is confused by how it is done now, and it makes it hard for people to match upstream packages with CentOS packages.
Despite the technical reasons, if the message is to confuse those users, you are on the right track.
We have been doing this exactly the same for 8 years.
Since 8 years ago some things have changed. 8 years ago there was no %{dist} tag. When there was a disttag, it used to be a fixed tag (eg. .el5), not el5_2.
There is no reason to reinvent the wheel here.
It is very simple ...
- If we do not change a package, it will have the exact same dist tag
as upstream.
So a %{dist} with .el5_2 stays .el5_2 on CentOS. No problem there.
- If we do change a package, then the dist tag will always be .el5.centos.
So a %{dist} with .el5_2.4 becomes .el5.centos.4, and there is no visual indication that both packages are related. Whereas .el5_2.centos.4 or .el5_2.4.centos would have been a more appropriate, and more correct (wrt. to depsolving) solution.
In the above example you may have noticed that .el5_2.4> .el5.centos.4, while .el5< .el5.centos
This is not confusing, and is exactly what we have been doing since we stood up CentOS.
With the difference that things have changed in the meantime which makes it confusing that httpd-2.2.3-45.el5_6.1.src.rpm on RHEL5 becomes httpd-2.2.3-45.el5.centos.1.src.rpm on CentOS5.
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
JML
On Thu, 5 May 2011, Jean-Marc Liger wrote:
Le 05/05/11 11:59, Dag Wieers a écrit :
On Wed, 4 May 2011, Johnny Hughes wrote:
On 05/04/2011 10:45 AM, Dag Wieers wrote:
On Wed, 4 May 2011, Karanbir Singh wrote:
On 05/04/2011 02:35 PM, Ned Slider wrote:
In such cases, would editing the SPEC file release line be the lesser of two evils?
maybe but it would convey the wrong message.
It depends on what message you want to send. Obviously Ned is confused by how it is done now, and it makes it hard for people to match upstream packages with CentOS packages.
Despite the technical reasons, if the message is to confuse those users, you are on the right track.
We have been doing this exactly the same for 8 years.
Since 8 years ago some things have changed. 8 years ago there was no %{dist} tag. When there was a disttag, it used to be a fixed tag (eg. .el5), not el5_2.
There is no reason to reinvent the wheel here.
It is very simple ...
- If we do not change a package, it will have the exact same dist tag
as upstream.
So a %{dist} with .el5_2 stays .el5_2 on CentOS. No problem there.
- If we do change a package, then the dist tag will always be
.el5.centos.
So a %{dist} with .el5_2.4 becomes .el5.centos.4, and there is no visual indication that both packages are related. Whereas .el5_2.centos.4 or .el5_2.4.centos would have been a more appropriate, and more correct (wrt. to depsolving) solution.
In the above example you may have noticed that .el5_2.4> .el5.centos.4, while .el5< .el5.centos
This is not confusing, and is exactly what we have been doing since we stood up CentOS.
With the difference that things have changed in the meantime which makes it confusing that httpd-2.2.3-45.el5_6.1.src.rpm on RHEL5 becomes httpd-2.2.3-45.el5.centos.1.src.rpm on CentOS5.
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
I know, the CentOS developers are simply ignoring the relevance of this.
It seems to be their new credo.
On Thu, 5 May 2011, Dag Wieers wrote:
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
I know, the CentOS developers are simply ignoring the relevance of this.
It seems to be their new credo.
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
On 05/05/2011 12:19 PM, Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
double standards based on the audience ? One of the reasons why I respected what you had to say was based around my, seemingly false, impression that you had conviction and honesty backing things up.
- KB
On Thu, 5 May 2011, Karanbir Singh wrote:
On 05/05/2011 12:19 PM, Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
double standards based on the audience ? One of the reasons why I respected what you had to say was based around my, seemingly false, impression that you had conviction and honesty backing things up.
The arguments have been ignored mostly, but yes, I try to be less harsh on the mailinglist. I am sure you say things privately different than publically too, depending on who you talk to.
That said, in my mail I did not say anything new. So double standards ? Not at all, things are just very senstitive on this mailinglist.
On Thursday, May 05, 2011 07:19:40 AM Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
As much as I respect your hard work on RPMforge over the years, I must comment on this.
If one replies differently in public than in private, it will leak publicly at some point, and the duplicity will be found out. E-mails, once sent, are written records, and can be copied and sent around all over. It is best to have the same face publicly as privately; that can either mean restraint in private or totally 'letting it all hang out' in public, as the sender of the message sees fit.
Having and raising five children has taught me extraordinarily valuable lessons on this, especially on how 'talking behind another's back' always comes back around, and always creates ill will.
On Thu, 5 May 2011, Lamar Owen wrote:
On Thursday, May 05, 2011 07:19:40 AM Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
As much as I respect your hard work on RPMforge over the years, I must comment on this.
If one replies differently in public than in private, it will leak publicly at some point, and the duplicity will be found out. E-mails, once sent, are written records, and can be copied and sent around all over. It is best to have the same face publicly as privately; that can either mean restraint in private or totally 'letting it all hang out' in public, as the sender of the message sees fit.
Having and raising five children has taught me extraordinarily valuable lessons on this, especially on how 'talking behind another's back' always comes back around, and always creates ill will.
There's nothing wrong with what I said. Nor the content, nor the tone. I stated the same thing publically as well, both here as elsewhere (blog, mailinglist, ...). The "double standards" theme is probably because of "So my response is how I reply privately." which is not what I meanted to say, I was simply pointing out that my reply was intended privately. But English is not my native language.
The only reason I apologised is because I don't think it should have been sent to the list, to not aggravate others needlessly.
On Thu, 5 May 2011, Lamar Owen wrote:
On Thursday, May 05, 2011 07:19:40 AM Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
As much as I respect your hard work on RPMforge over the years, I must comment on this.
If one replies differently in public than in private, it will leak publicly at some point, and the duplicity will be found out. E-mails, once sent, are written records, and can be copied and sent around all over. It is best to have the same face publicly as privately; that can either mean restraint in private or totally 'letting it all hang out' in public, as the sender of the message sees fit.
Having and raising five children has taught me extraordinarily valuable lessons on this, especially on how 'talking behind another's back' always comes back around, and always creates ill will.
Lamar,
I respect your opinion. But you may not have noticed that KB and Johnny are ignoring the whole discussion and he prefers to go into things that do not matter. Even a reply I did not intend to send to the list.
I am not making anything up, and I am glad that Ned actually has proof of the problem we are trying to bring up. But as usual smoke and mirrors are prefered to distract people from the issue brought up.
So I think you fell in one of the traps to mischaracterize me, and make it personal. I know the tactics used by now.
On Thu, 5 May 2011, Dag Wieers wrote:
On Thu, 5 May 2011, Lamar Owen wrote:
On Thursday, May 05, 2011 07:19:40 AM Dag Wieers wrote:
I am sorry for this. Because this mail arrived in my inbox, I was confident Jean-Marc was mailing me privately. So my response is how I reply privately. I did not intend to send this to the list.
As much as I respect your hard work on RPMforge over the years, I must comment on this.
So I think you fell in one of the traps to mischaracterize me, and make it personal. I know the tactics used by now.
Ok, I seem to be unable to use a mail-client properly and send another mail to the list that I did not want to bring up here. So let me make this easy on everyone. I will unsubscribe from this list.
On 5/5/2011 11:20 AM, Dag Wieers wrote:
I respect your opinion. But you may not have noticed that KB and Johnny are ignoring the whole discussion and he prefers to go into things that do not matter.
Yes, I took that as an observation, not an opinion that needed to be kept private... Can anyone think otherwise?
On Thu, 5 May 2011, Les Mikesell wrote:
Yes, I took that as an observation, not an opinion that needed to be kept private... Can anyone think otherwise?
Certainly 'anyone' can think otherwise; I do, for example, for upon the following analyses:
Procedural: They (hughesjr and singh) said their piece, and they shut up, unlike many here who need entertainment of trolling or badgering endlessly -- This is: talkers vs. doers all over again. Eventually the 'doers' ignore the 'talkers' and return to their work
Substantive: Upstream has a mode using Z streams, %{_isa} tags, mal-placed %{dist} tags, famously had several people holding @redhat email address holders argue against %{repo} tags in the EPEL context, and other mechanisms that do not all work with a strict NEVR resolution by rpmlib and rpmvercmp [ie, a simple 'yum update' model]; formerly package dependency computations were done against a Oracle database backend in the RHN model on the server side
'Ned Slider' points out (correctly, to my thinking for reasons, infra) that the Rel tag is sometimes comprised of an extension containing the %{dist} tag -- and THEN OTHER STUFF [seeming a Z channel indicator, or ${_isa}] expansion, or simply a manual edit to the RIGHT of a macro-expanded tag]
Eventually rpmvercmp as it walks through the sequential element and sub-element comparisons it does, MAY reach such, or it may NOT and it MAY matter in determining on an automatic basis which of two pakages is intended to be 'later'
It is rare, but I have seen examples, particularly in the 6 sources, and in RawHide, as there are thousands of people managing these tags in the latter and 'stuff' happens. There are some really ** wrong ** Rel tags containing Ver information, in some of the 'R' statistical add-on packages out of the upstream's Enterprise side, from a year back or so [and indeed the 'R' add-on modules practice contemplates slip-streamed versions all bearig the same source tarball versioning -- making matters even worse] -- I repackaged around the upstream's 'errors', and track several R adjunct archives CRAN, Bio, R-Forge, 'looking' for changes using mirroring and daily md5sum diffs to spot such 'slip-streaming', to get my builders to work for some customers of supplemental content
But at the end of the day, these choices belong to the upstream. Their sources, and their choices. CentOS does not own them, and does not control them; it can only react to them under our touchstone rule 'forever' of a 'strict rebuild, with minimal changes for the updater, trademark elidement, and branding changes'
Perhaps the Rel 'cruft' is conscious, perhaps due to poor internal communication of how a malformed Rel entry breaks yum or other naiive dependency solvers; perhaps simply unknowing due to the computational complexity of the problem-space and running multiple products -- it does not matter which applies, because further ...
CentOS 'flattens' that N dimensional space those product variations represent; sometimes, this means that ** any ** EVR comparison can be 'wrong' from the rpmlib point of view, cpmpared to what may be internally desired by a sysadmin.
And it does no good to get 'exercised' about it -- testing shows the issue; Lamar's example seems to be correct upon inspection, but darn it, it is just not worth getting wound up on -- Add an 'exclude=' to hold out an error (tin his example, ntp, rpm -e it, and then yum the false to reality 'earlier but correct' NEVR package right back in --- no need for tears.
Why I remember that the former RHL days that the community's Postgresql packager tried to accomodate all schema and store procedure unloads and reloads, so that a person using just RPM to upgrade across a major release did not even need to read release notes or take backups -- too much sleep was lost on this task, trying to solve that riddle within a Turing complete language space
This is why, rather, one has a testbed to burn up, before applying updates to critical or production systems, and 'change control' processes permitting roll-backs to prior images if something unexpected goes horribly wrong
If a person wants to have someone listen to them carp about this; or to take, test and manage backups; or to have a deterministic path solved on your behalf, there are vendors who will sell such services to all comers at varying levels of quality -- but the CentOS project is not such a vendor
It also means (under Godel's theorem, assuming either a random, or a malicious party feeding 'noise' into the system) that no single set of patches ** can ** work in all cases, both for the foregoing reasons, and because this is a moving target requiring perfect predictive future knowledge of the EVR changes a given package going to take
Read 'Godel, Escher and Bach' for more context --- 'tea leaf reading' the upstream is out of scope here
-- Russ herrold
2011/5/6 R P Herrold herrold@owlriver.com
[...] Procedural: They (hughesjr and singh) said their piece, and they shut up, unlike many here who need entertainment of trolling or badgering endlessly -- This is: talkers vs. doers all over again. Eventually the 'doers' ignore the 'talkers' and return to their work [...]
Great statement, God has spoken, now everyone from the crowd has to be happy that God spoke to him and he should definitely shut up from this point. Please crowd, don't respond to a mail that God send, there shouldn't be any kind of discussion after that mail because God is right, every time without any exception. You've made my day ...
Regards, Thomas
On 05/06/2011 05:41 AM, Thomas Bendler wrote:
2011/5/6 R P Herrold <herrold@owlriver.com mailto:herrold@owlriver.com>
[...] Procedural: They (hughesjr and singh) said their piece, and they shut up, unlike many here who need entertainment of trolling or badgering endlessly -- This is: talkers vs. doers all over again. Eventually the 'doers' ignore the 'talkers' and return to their work [...]Great statement, God has spoken, now everyone from the crowd has to be happy that God spoke to him and he should definitely shut up from this point. Please crowd, don't respond to a mail that God send, there shouldn't be any kind of discussion after that mail because God is right, every time without any exception. You've made my day ...
We are doing what we are doing
We are not changing mid stream.
I don't care if you like it or not.
Millions of users have built scripts that depend on certain rules, like our use of dist tags, to remain constant.
A couple of comments on a mailing list, because someone has a good idea, does not mean that we need to change things that cause these people to rewire their scripts. It is just not going to happen mid stream.
Now, if you (or anyone else here) doesn't like it ... well, it is not changing mid stream.
What we CAN discuss is the possibility that in the NEWER distributions, we maybe do it differently (ie, C6).
2011/5/6 Johnny Hughes johnny@centos.org
[...]
We are doing what we are doing
What a great conclusion.
We are not changing mid stream. I don't care if you like it or not.
Also not really astonishing.
Millions of users have built scripts that depend on certain rules, like our use of dist tags, to remain constant.
Millions of user are not able to write a script so they certainly don't have scripts using the dist tag.
A couple of comments on a mailing list, because someone has a good idea,
does not mean that we need to change things that cause these people to rewire their scripts. It is just not going to happen mid stream.
The billions of people who use scripts which rely on the dist tag? But if you don't want to improve the distribution let it as it is.
[...]
What we CAN discuss is the possibility that in the NEWER distributions, we maybe do it differently (ie, C6).
Better would be C7, it will give the trillions of users enough time to change there scripts which make use of the dist tag.
Regards, Thomas
On 5/6/2011 12:15 PM, Thomas Bendler wrote:
The billions of people who use scripts which rely on the dist tag? But if you don't want to improve the distribution let it as it is.
Have dist tags ever been documented as having a meaning that you can rely on? If not, I guess those scripts would have, as they say, "undocumented behavior".
On 06/05/11 18:29, Les Mikesell wrote:
On 5/6/2011 12:15 PM, Thomas Bendler wrote:
The billions of people who use scripts which rely on the dist tag? But if you don't want to improve the distribution let it as it is.
Have dist tags ever been documented as having a meaning that you can rely on? If not, I guess those scripts would have, as they say, "undocumented behavior".
Yes, it is documented that %{dist} should only be used to define the distribution that a package was built against, and should only be used in the Release field.
As such, the %{dist} tag as used in the Release field will be considered by rpm (and thus yum) when doing NEVR determinations.
That is well documented and is unlikely to change.
On 05/06/2011 03:43 PM, Charlie Brady wrote:
On Fri, 6 May 2011, Johnny Hughes wrote:
Millions of users have built scripts that depend on certain rules, like our use of dist tags, to remain constant.
Millions? Really? And you made promises that your use of dist tags would remain constant?
We explained how we do dist tags, yes. We said .el<X>.centos would be used for packages that are modified.
CentOS has millions of users, yes. The current estimate is somewhere around 4 million.
CentOS is installed on more Web servers that Fedora and Red Hat Enterprise Linux combined:
Centos: 29.2% (Linux), 9.3% (Entire Web) RHEL: 14.5% (Linux), 4.6% (Entire Web) Fedora: 6.5% (Linux), 2.1% (Entire Web)
So yes, Charlie, there are millions of machines that use CentOS.
At least 8 of the top 500 super computers in world run CentOS.
Almost everyone one of them has some kind of script written for it. Do all of them care about dist tag. Of course not.
However, if we make a major change (like changing our dist tag), we have no idea how it will impact people. What kind of puppet deploy rules out there might have .el5.centos in their rules? How about cobbler? What about people's kickstarts? How about the guys that use spacewalk. What about the major corporation that pulls out all the .centos files and replaces those with their own, etc.
I know how it will impact me personally ... it will require several python, bash and perl scripts to be rewritten in the system that we use to build, mirror, and distribute CentOS. It will impact everything from the scripts that we use to pull down files from upstream and where they get put to how we check files against each other, to how we send e-mails to the announce list, etc., etc.
Who knows the impact on the Example ISP who is host 50,000 CentOS servers using CPanel or the Example2 ISP that does all their machines on xen VMs ahd deploys with cobbler. What about the OSes that use CentOS as a basis for them (ClearOS, Rocks Clusters, etc.).
The point is, we can't just change things mid stream because we have no idea what scripts and software from which users might do something with dist tag.
I can tell you that when Red Hat changed the way they did dist tag, it had a major impact on the CentOS Project. We changing our dist tag could have the same kind of impact on others. 9.3% of the world's Internet runs on CentOS. 9.3% ... quite a lot.
On 05/06/2011 04:58 PM, Johnny Hughes wrote:
On 05/06/2011 03:43 PM, Charlie Brady wrote:
On Fri, 6 May 2011, Johnny Hughes wrote:
Millions of users have built scripts that depend on certain rules, like our use of dist tags, to remain constant.
Millions? Really? And you made promises that your use of dist tags would remain constant?
We explained how we do dist tags, yes. We said .el<X>.centos would be used for packages that are modified.
CentOS has millions of users, yes. The current estimate is somewhere around 4 million.
CentOS is installed on more Web servers that Fedora and Red Hat Enterprise Linux combined:
Centos: 29.2% (Linux), 9.3% (Entire Web) RHEL: 14.5% (Linux), 4.6% (Entire Web) Fedora: 6.5% (Linux), 2.1% (Entire Web)
So yes, Charlie, there are millions of machines that use CentOS.
At least 8 of the top 500 super computers in world run CentOS.
Almost everyone one of them has some kind of script written for it. Do all of them care about dist tag. Of course not.
However, if we make a major change (like changing our dist tag), we have no idea how it will impact people. What kind of puppet deploy rules out there might have .el5.centos in their rules? How about cobbler? What about people's kickstarts? How about the guys that use spacewalk. What about the major corporation that pulls out all the .centos files and replaces those with their own, etc.
I know how it will impact me personally ... it will require several python, bash and perl scripts to be rewritten in the system that we use to build, mirror, and distribute CentOS. It will impact everything from the scripts that we use to pull down files from upstream and where they get put to how we check files against each other, to how we send e-mails to the announce list, etc., etc.
Who knows the impact on the Example ISP who is host 50,000 CentOS servers using CPanel or the Example2 ISP that does all their machines on xen VMs ahd deploys with cobbler. What about the OSes that use CentOS as a basis for them (ClearOS, Rocks Clusters, etc.).
The point is, we can't just change things mid stream because we have no idea what scripts and software from which users might do something with dist tag.
I can tell you that when Red Hat changed the way they did dist tag, it had a major impact on the CentOS Project. We changing our dist tag could have the same kind of impact on others. 9.3% of the world's Internet runs on CentOS. 9.3% ... quite a lot.
Here are a couple other references:
Amazon EC2: http://www.bio-itworld.com/news/04/25/2011/Meet-Tanuki-ten-thousand-core-sup...
On Thu, May 05, 2011 at 01:17:23PM +0200, Dag Wieers wrote:
(49 lines of noise trimmed out)
I know, the CentOS developers are simply ignoring the relevance of this.
It seems to be their new credo.
So Dag... How's DagOS coming along?
John
On Thu, 5 May 2011, John R. Dennison wrote:
On Thu, May 05, 2011 at 01:17:23PM +0200, Dag Wieers wrote:
(49 lines of noise trimmed out)
I know, the CentOS developers are simply ignoring the relevance of this.
It seems to be their new credo.
So Dag... How's DagOS coming along?
We are not supposed to discuss competing projects on this list, even if they are fictitious :)
On 05/05/2011 12:17 PM, Dag Wieers wrote:
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
I know, the CentOS developers are simply ignoring the relevance of this.
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
It seems to be their new credo.
troll
- KB
On Thu, 5 May 2011, Karanbir Singh wrote:
On 05/05/2011 12:17 PM, Dag Wieers wrote:
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
I know, the CentOS developers are simply ignoring the relevance of this.
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
It seems to be their new credo.
troll
It's funny to learn that if there was a way to prevent that mail from being send to the list, only a few seconds after it was send, I would not have been a troll.
I'll just assume that you would have prevented your name-calling as well, a few seconds after you hit the "Send" button.
No problem, I'll wait for the apology mail as well.
Le 05/05/11 13:22, Karanbir Singh a écrit :
On 05/05/2011 12:17 PM, Dag Wieers wrote:
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
Karanbir,
Let's have a little clarification. I wrote the above paragraph and I assume it. Dag wrote the (indigo) sentences below and I got them out of my post because I don't agree. I'm not with or against someone. I just want to discuss on a devel list, not to troll or give any food to some flam war.
I know, the CentOS developers are simply ignoring the relevance of this.
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
Ok, I assume that say that _x and _y having been built on different instances would have been a more correct assertion, but after saying that, doesn't the difference between these two instances still remains.
JML
It seems to be their new credo.
troll
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 05/05/2011 01:02 PM, Jean-Marc Liger wrote:
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
Ok, I assume that say that _x and _y having been built on different instances would have been a more correct assertion, but after saying that, doesn't the difference between these two instances still remains.
that depends on how you define 'instances'
- KB
Le 05/05/11 14:27, Karanbir Singh a écrit :
On 05/05/2011 01:02 PM, Jean-Marc Liger wrote:
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
Ok, I assume that say that _x and _y having been built on different instances would have been a more correct assertion, but after saying that, doesn't the difference between these two instances still remains.
that depends on how you define 'instances'
I define 'instance' like the build environment CentOS projet take care to reconstruct from scratch for each new release or sub-release of RHEL. And, after reading the several posts about it, I understood that, for binary compatibility 'soname to soname', CentOS' packages couldn't always be self-hosted, because Upstream doesn't.
JML
On 05/05/2011 01:49 PM, Jean-Marc Liger wrote:
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
Ok, I assume that say that _x and _y having been built on different instances would have been a more correct assertion, but after saying
I define 'instance' like the build environment CentOS projet take care
in that case, no - the distag in this case will have no connection or relevance to the build roots being used to build any given package. In many cases it might 'ok' to assume this ( eg. package-.el5_1 will clear have a different root to package-.el5_5 ) but beyond that.
Look at it from a different point of view: there are el5_6 packages that were built on el5.5 buildroots, while there are el5_5 updates that were built with packages that had el5_6 in their released names.
- KB
Le 05/05/11 14:57, Karanbir Singh a écrit :
On 05/05/2011 01:49 PM, Jean-Marc Liger wrote:
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
Ok, I assume that say that _x and _y having been built on different instances would have been a more correct assertion, but after saying
I define 'instance' like the build environment CentOS projet take care
in that case, no - the distag in this case will have no connection or relevance to the build roots being used to build any given package. In many cases it might 'ok' to assume this ( eg. package-.el5_1 will clear have a different root to package-.el5_5 ) but beyond that.
Look at it from a different point of view: there are el5_6 packages that were built on el5.5 buildroots,
Ok, the first packages of a new sub-release are built on the previous buildroot.
while there are el5_5 updates that were built with packages that had el5_6 in their released names.
Looks like Upstream still have 'rawhide' habits.
For a new sub-release, do you have some new or updated srpms (unmodified by CentOS) coming with several dist tags ?
On 05/05/2011 02:52 PM, Jean-Marc Liger wrote:
Look at it from a different point of view: there are el5_6 packages that were built on el5.5 buildroots,
Ok, the first packages of a new sub-release are built on the previous buildroot.
there is no connection to 'new' or 'old' packages, the release order has no mapping back to build order.
For a new sub-release, do you have some new or updated srpms (unmodified by CentOS) coming with several dist tags ?
all centos mod packages have dist set to .el5.centos or .el4.centos or .el3.centos etc
Le 05/05/11 16:02, Karanbir Singh a écrit :
On 05/05/2011 02:52 PM, Jean-Marc Liger wrote:
Look at it from a different point of view: there are el5_6 packages that were built on el5.5 buildroots,
Ok, the first packages of a new sub-release are built on the previous buildroot.
there is no connection to 'new' or 'old' packages, the release order has no mapping back to build order.
Is your previous statement was about CentOS or Upstream ? I understood Upstream.
For a new sub-release, do you have some new or updated srpms (unmodified by CentOS) coming with several dist tags ?
all centos mod packages have dist set to .el5.centos or .el4.centos or .el3.centos etc
My question was about unmodified packages. JML
On 05/05/2011 03:18 PM, Jean-Marc Liger wrote:
Is your previous statement was about CentOS or Upstream ? I understood Upstream.
both. The bit that is important here is that the tag has no connection to build root's being used.
My question was about unmodified packages.
we just try and match whats being used upstream for unmodified packages ( I thought that was already quite clear )
- KB
Le 05/05/11 16:31, Karanbir Singh a écrit :
On 05/05/2011 03:18 PM, Jean-Marc Liger wrote:
Is your previous statement was about CentOS or Upstream ? I understood Upstream.
both. The bit that is important here is that the tag has no connection to build root's being used.
My question was about unmodified packages.
we just try and match whats being used upstream for unmodified packages ( I thought that was already quite clear )
It was. But the initial question was : for same sub-release for example 5.6, could you have new or updated srpms, which wasn't in release/update 5.5, to rebuild with two different dist tags for example el5_5 and el5_6.
JM
On 05/05/2011 03:40 PM, Jean-Marc Liger wrote:
It was. But the initial question was : for same sub-release for example 5.6, could you have new or updated srpms, which wasn't in release/update 5.5, to rebuild with two different dist tags for example el5_5 and el5_6.
why would you be rebuilding the same srpm on 5.6 once its already done and released under 5.5 ? as I said already, the disttag isnt used in the EVR compares for new package EVR > older package EVR
the only place where this isnt true is the z-series packages, which we dont built anyway. And even if we did the new package EVR does not need to be higher than old package EVR
- KB
Le 05/05/11 16:48, Karanbir Singh a écrit :
On 05/05/2011 03:40 PM, Jean-Marc Liger wrote:
It was. But the initial question was : for same sub-release for example 5.6, could you have new or updated srpms, which wasn't in release/update 5.5, to rebuild with two different dist tags for example el5_5 and el5_6.
why would you be rebuilding the same srpm on 5.6 once its already done and released under 5.5 ? as I said already, the disttag isnt used in the EVR compares for new package EVR> older package EVR
I understand that. My question is only for new srpms in 5.6, which hadn't be released in 5.5, could we found differents disttags for theses new packages, i.e. el5_6 and el5_5 or el5_else, or the disttag is always el5_6 for theses new packages ?
JML
On 05/05/2011 04:03 PM, Jean-Marc Liger wrote:
I understand that. My question is only for new srpms in 5.6, which hadn't be released in 5.5, could we found differents disttags for theses new packages, i.e. el5_6 and el5_5 or el5_else, or the disttag is always el5_6 for theses new packages ?
depends on what is released from usptream, it will be either .el5 or .el5_6 or .el5_5
updates from a few days back had .el4_8 ( as an example ), even though el4.9 is released now.
- KB
Le 05/05/11 14:02, Jean-Marc Liger a écrit :
Le 05/05/11 13:22, Karanbir Singh a écrit :
On 05/05/2011 12:17 PM, Dag Wieers wrote:
The most important thing is RHEL5_X now sligthly differs with RHEL5_Y, and this may affect compatibility, like with the last mod_nss release. So I have an interest to immediatly visualise that my foo package, modified by CentOS, was rebuilt on el5_X rather than el5_Y.
Karanbir,
Let's have a little clarification. I wrote the above paragraph and I assume it. Dag wrote the (indigo) sentences below and I got them out of my post because I don't agree. I'm not with or against someone. I just want to discuss on a devel list, not to troll or give any food to some flam war.
I just recieve the first post Dag intended for me and the list got aslo got... Sorry, part of my last answer was based on some misunderstood... Please could we now focus on the technical point of vue ?
I know, the CentOS developers are simply ignoring the relevance of this.
by assuming that the _x and _y imply that the code is built on, you already dont know what you are talking about
It seems to be their new credo.
troll
- KB
On 05/05/11 04:51, Johnny Hughes wrote:
- If we do change a package, then the dist tag will always be .el5.centos.
This is not confusing, and is exactly what we have been doing since we stood up CentOS.
What is confusing about this?
So which upstream source package was this CentOS package built from:
ntp-4.2.2p1-9.el5.centos.1.i386.rpm
and the choices are...
1. ntp-4.2.2p1-9.el5.src.rpm 2. ntp-4.2.2p1-9.el5_3.1.src.rpm 3. ntp-4.2.2p1-9.el5_3.2.src.rpm 4. ntp-4.2.2p1-9.el5_4.1.src.rpm
from the logic presented above, it could be either package 2 or package 4.
That is what is confusing.
Furthermore, from the scheme outlined above, the corresponding CentOS packages would look like:
1. ntp-4.2.2p1-9.el5.src.rpm ==> ntp-4.2.2p1-9.el5.centos.src.rpm 2. ntp-4.2.2p1-9.el5_3.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm 3. ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm 4. ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
Oops, package 4 is now the same as package 2 and won't ever update package 3 as intended by upstream
Now do you [sic] see the problem? Obviously you do as you [CentOS] released the package (4) as ntp-4.2.2p1-9.el5.centos.2.1.src.rpm to solve the problem you have created, which leaves users equally confused as to which SRPM this might have been built from as there is no equivalent upstream ntp-4.2.2p1-9.el5[_x].2.1.src.rpm package (yet).
One wonders how you will deal with ntp-4.2.2p1-9.el5_6.1.src.rpm should it ever be released by upstream?
All I was trying to say was that if you were to release package (4) as ntp-4.2.2p1-9.el5_4.centos.1.src.rpm (by using the dist tag of el5_4.centos as upstream does, and as you do for other non-centos modified packages) then a) you wouldn't have to solve the EVR problem you just created, and as a result b) it would be more obvious which upstream package your package is built from.
On 05/05/2011 04:15 PM, Ned Slider wrote:
- ntp-4.2.2p1-9.el5.src.rpm ==> ntp-4.2.2p1-9.el5.centos.src.rpm
- ntp-4.2.2p1-9.el5_3.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
is that what really happened ?
On 05/05/11 16:42, Karanbir Singh wrote:
On 05/05/2011 04:15 PM, Ned Slider wrote:
- ntp-4.2.2p1-9.el5.src.rpm ==> ntp-4.2.2p1-9.el5.centos.src.rpm
- ntp-4.2.2p1-9.el5_3.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
is that what really happened ?
Yes, and as a result CentOS released ntp-4.2.2p1-9.el5_4.1.src.rpm as ntp-4.2.2p1-9.el5.centos.2.1.src.rpm because you couldn't release it according to your versioning scheme because in this case it's broken.
But I wrote all this perfectly clearly in my previous mail, and you know exactly what happened so I don't really see the point of your question other than to avoid addressing the issue?
On 05/05/2011 04:58 PM, Ned Slider wrote:
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
Yes, and as a result CentOS released ntp-4.2.2p1-9.el5_4.1.src.rpm as ntp-4.2.2p1-9.el5.centos.2.1.src.rpm because you couldn't release it according to your versioning scheme because in this case it's broken.
There was also a patch issue iirc, dont have the details right now.
But I wrote all this perfectly clearly in my previous mail, and you know exactly what happened so I don't really see the point of your question other than to avoid addressing the issue?
Not sure how you worked that out - where does it say that we cant and wont bump local release to make sure that packages are not of a higher EVR than whats already been released ?
Based on your assumption - we would never be able to do local fix's for anything. Sit back and think it through. There is a clear reason to create that .centos. differentiation. And if we need to to rebuilds and re-releases for a package, it will almost certainly have either an added element or a local bump in the element.
- KB
On 05/05/11 17:03, Karanbir Singh wrote:
On 05/05/2011 04:58 PM, Ned Slider wrote:
But I wrote all this perfectly clearly in my previous mail, and you know exactly what happened so I don't really see the point of your question other than to avoid addressing the issue?
Not sure how you worked that out -
What I have worked out is that you have stated on numerous occasions in this thread that the dist tag isn't used in EVR determinations and I responded by showing a clear example (ntp) where it is.
Now, and I'm being gracious here, as I was only able to find one example I will admit that it _could_ have been an unintentional error on the part of upstream, but that does not change the fact that the dist tag is used as illustrated in that example.
What would have been nice is if you could have been equally gracious, accepted that fact and acknowledged it rather than retorting with rhetorical questions and derogatory implications (in other channels) that I must be "smoking" something.
I raised a very simple and straight forward point in starting this thread, and I get the impression that the majority of other responders herein feel likewise, yet we seem to constantly end up at a place very OT from my original point.
I will reiterate one last time:
If you were to use a dist tag of el5_6.centos, for example, rather than el5.centos (where upstream uses el5_6) then:
1. CentOS package naming will be closer to that of upstream than it is now, and 2. it will be more obvious to end users which upstream SRPM a given CentOS package is built from.
all of which IMHO would be a good thing given CentOS aims to track upstream as closely as possible.
Hi,
On 05/05/2011 06:20 PM, Ned Slider wrote:
What I have worked out is that you have stated on numerous occasions in this thread that the dist tag isn't used in EVR determinations and I responded by showing a clear example (ntp) where it is.
Yes, I still stick by that; its based on what we have found over the years and what we have been told in various communication. As you said the ntp package is the only example otherwise - and I'm fairly sure it was a slip up from someone.
What would have been nice is if you could have been equally gracious, accepted that fact and acknowledged it rather than retorting with rhetorical questions and derogatory implications (in other channels) that I must be "smoking" something.
and I explained why.
I raised a very simple and straight forward point in starting this thread, and I get the impression that the majority of other responders
sure, the point you raised is valid. I just dont see the problems its trying to solve as being real problems. Comments inline:
If you were to use a dist tag of el5_6.centos, for example, rather than el5.centos (where upstream uses el5_6) then:
- CentOS package naming will be closer to that of upstream than it is
now, and
yes, but it will change within the scope of the package / build cycle itself. We do make the extra effort to make sure that people can see clearly what changes are there, what packages they are in and then track them through the life of the release.
- it will be more obvious to end users which upstream SRPM a given
CentOS package is built from.
There are plenty of ways to workout what srpm a specific centos package is built from, including changelog tracking and even using specific metadata from srpms and comparing that. the dist portion is easy to specify and track in that way ( and tbh, just doing name compares isnt very convincing, even the 3 -'s from the right process is liable to break down )
Besides how would that scale to packages that are rebuilt or fixed post release - there needs to be a version or release bump and that takes it out of sync with this scheme of things. Sticking with the .el5.centos seems to make the most sense ( to me anyway, and I've not seen any reason brought up so far to prove otherwise ).
all of which IMHO would be a good thing given CentOS aims to track upstream as closely as possible.
yes, and we also aim to make it very clear when we change things - and changing the way we do that almost 50% of the way through the lifecycle of the release, with no-clear-problem to solve, still sounds like something that isnt worth doing.
Perhaps something to consider for C6, but not for C5. Lots of people already have established expectations on what is coming through the funnel.
- KB
On 05/05/11 18:37, Karanbir Singh wrote:
On 05/05/2011 06:20 PM, Ned Slider wrote:
I raised a very simple and straight forward point in starting this thread, and I get the impression that the majority of other responders
sure, the point you raised is valid. I just dont see the problems its trying to solve as being real problems.
Great, we got there at last! That's all I'm looking for. If you don't think it's worth fixing then that's fine - I respect that, it's your project.
Le 05/05/11 19:37, Karanbir Singh a écrit :
Hi,
On 05/05/2011 06:20 PM, Ned Slider wrote:
If you were to use a dist tag of el5_6.centos, for example, rather than el5.centos (where upstream uses el5_6) then:
- CentOS package naming will be closer to that of upstream than it is
now, and
...
all of which IMHO would be a good thing given CentOS aims to track upstream as closely as possible.
yes, and we also aim to make it very clear when we change things - and changing the way we do that almost 50% of the way through the lifecycle of the release, with no-clear-problem to solve, still sounds like something that isnt worth doing.
Yes, as there is issue to solve, it may bring some confusion.
Perhaps something to consider for C6, but not for C5. Lots of people already have established expectations on what is coming through the funnel.
But, considering the fact that modifiied el4_X and el5_Y dist naming tags had been used by Upstream after the beginning of the CentOS project, it should be interesting to fully integrate these changes in CentOS 6.
JML
Le 06/05/11 14:26, Jean-Marc Liger a écrit :
Le 05/05/11 19:37, Karanbir Singh a écrit :
Hi,
On 05/05/2011 06:20 PM, Ned Slider wrote:
If you were to use a dist tag of el5_6.centos, for example, rather than el5.centos (where upstream uses el5_6) then:
- CentOS package naming will be closer to that of upstream than it is
now, and
...
all of which IMHO would be a good thing given CentOS aims to track upstream as closely as possible.
yes, and we also aim to make it very clear when we change things - and changing the way we do that almost 50% of the way through the lifecycle of the release, with no-clear-problem to solve, still sounds like something that isnt worth doing.
Yes, as there is issue to solve, it may bring some confusion.
Please read : Yes, as there is NO issue to solve, it may bring some confusion.
Perhaps something to consider for C6, but not for C5. Lots of people already have established expectations on what is coming through the funnel.
But, considering the fact that modifiied el4_X and el5_Y dist naming tags had been used by Upstream after the beginning of the CentOS project, it should be interesting to fully integrate these changes in CentOS 6.
JML _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thursday, May 05, 2011 12:03:07 PM Karanbir Singh wrote:
On 05/05/2011 04:58 PM, Ned Slider wrote:
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
Yes, and as a result CentOS released ntp-4.2.2p1-9.el5_4.1.src.rpm as ntp-4.2.2p1-9.el5.centos.2.1.src.rpm because you couldn't release it according to your versioning scheme because in this case it's broken.
[snip]
Based on your assumption - we would never be able to do local fix's for anything. Sit back and think it through. There is a clear reason to create that .centos. differentiation.
I told someone else I was going to sleep on this reply, but, I think I'm pretty clear on what I'm saying....
Why could the package versioning not have been:
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5_3.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5_4.centos.1.src.rpm
instead of what was chosen?
I think that's what Ned is talking about; adding the .centos. is appropriate, but giving a clear indication of which upstream source RPM is the origin of the modified source RPM is a good thing, no? The fact that Ned is confused about the reason speaks volumes; I likewise, not really having been aware of this before, am confused why you would want to throw away (or relocate) the '_3' and '_4' in the modified source RPM's versioning. And it has nothing, in my mind, to do with the EVR comparison; it has to do with being able to correlate the centos-modified source RPM with the upstream source RPM from which the centos version is derived.
Of course, I reserve the right to be wrong, but that's how I'm understanding the confusion at this juncture. And Ned, please correct me if I've missed what you're saying.
On 05/05/2011 12:49 PM, Lamar Owen wrote:
On Thursday, May 05, 2011 12:03:07 PM Karanbir Singh wrote:
On 05/05/2011 04:58 PM, Ned Slider wrote:
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5.centos.1.src.rpm
Yes, and as a result CentOS released ntp-4.2.2p1-9.el5_4.1.src.rpm as ntp-4.2.2p1-9.el5.centos.2.1.src.rpm because you couldn't release it according to your versioning scheme because in this case it's broken.
[snip]
Based on your assumption - we would never be able to do local fix's for anything. Sit back and think it through. There is a clear reason to create that .centos. differentiation.
I told someone else I was going to sleep on this reply, but, I think I'm pretty clear on what I'm saying....
Why could the package versioning not have been:
- ntp-4.2.2p1-9.el5_3.2.src.rpm ==> ntp-4.2.2p1-9.el5_3.centos.2.src.rpm
- ntp-4.2.2p1-9.el5_4.1.src.rpm ==> ntp-4.2.2p1-9.el5_4.centos.1.src.rpm
instead of what was chosen?
I think that's what Ned is talking about; adding the .centos. is appropriate, but giving a clear indication of which upstream source RPM is the origin of the modified source RPM is a good thing, no? The fact that Ned is confused about the reason speaks volumes; I likewise, not really having been aware of this before, am confused why you would want to throw away (or relocate) the '_3' and '_4' in the modified source RPM's versioning. And it has nothing, in my mind, to do with the EVR comparison; it has to do with being able to correlate the centos-modified source RPM with the upstream source RPM from which the centos version is derived.
Of course, I reserve the right to be wrong, but that's how I'm understanding the confusion at this juncture. And Ned, please correct me if I've missed what you're saying.
Upstream has said that they would not number in that manner ... now that they are doing so with some packages, that is, indeed, a problem.
On Friday, May 06, 2011 11:02:27 AM Johnny Hughes wrote:
On 05/05/2011 12:49 PM, Lamar Owen wrote:
... I likewise, not really having been aware of this before, am confused why you would want to throw away (or relocate) the '_3' and '_4' in the modified source RPM's versioning. And it has nothing, in my mind, to do with the EVR comparison; it has to do with being able to correlate the centos-modified source RPM with the upstream source RPM from which the centos version is derived.
Upstream has said that they would not number in that manner ... now that they are doing so with some packages, that is, indeed, a problem.
Well, it seems to me (but I'm not one impacted by the versioning, to change or not to change is irrelevant to my current needs, unless the versioning breaks updates, since 'yum update' should "Just Work" without issue) that, to be fully bug-for-bug compatible, even though this versioning is 'buggy' in its usage, propagating it downstream would be desireable. But it would be interesting to see how many would be affected either way, since there's probably not too many delve into the Release field at that level.
And perhaps it's time for a bugzilla.r.c bug report on the versioning.... although I think that bug would not have a high likelihood of seeing any attention, since it doesn't affect upstream's updating or source correlation.
But if it's low-hanging fruit to match release from upstream with the .centos. addition for modified source RPMs, then it seems to me to be a worthy thing to do, even for C5, but.... after C6 is out.
-
Charlie Brady -
Dag Wieers -
David Hollis -
Jean-Marc Liger -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Ned Slider -
R P Herrold -
Thomas Bendler