FAQ
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?

Search Discussions

  • Karanbir Singh at May 4, 2011 at 9:51 am

    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
  • David Hollis at May 4, 2011 at 10:51 am

    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)?
  • Karanbir Singh at May 4, 2011 at 11:52 am

    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
  • Ned Slider at May 4, 2011 at 1:00 pm

    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.
  • Karanbir Singh at May 4, 2011 at 1:06 pm

    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
  • Dag Wieers at May 4, 2011 at 1:54 pm

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Karanbir Singh at May 5, 2011 at 6:54 am

    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
  • Dag Wieers at May 4, 2011 at 11:45 am

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Johnny Hughes at May 4, 2011 at 11:51 pm

    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?

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110504/9f310dd4/attachment.bin
  • Dag Wieers at May 5, 2011 at 5:59 am

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

    1. 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.

    2. 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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Jean-Marc Liger at May 5, 2011 at 7:13 am

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

    1. 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.
    2. 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
  • Dag Wieers at May 5, 2011 at 7:17 am

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

    1. 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.
    2. 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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Dag Wieers at May 5, 2011 at 7:19 am

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Karanbir Singh at May 5, 2011 at 7:38 am

    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
  • Dag Wieers at May 5, 2011 at 7:46 am

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Lamar Owen at May 5, 2011 at 10:19 am

    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.
  • Dag Wieers at May 5, 2011 at 12:11 pm

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Dag Wieers at May 5, 2011 at 12:20 pm

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Dag Wieers at May 5, 2011 at 12:23 pm

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Les Mikesell at May 5, 2011 at 12:51 pm

    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?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • R P Herrold at May 5, 2011 at 11:43 pm

    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
  • Thomas Bendler at May 6, 2011 at 6:41 am
    2011/5/6 R P Herrold [...]
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110506/cba39205/attachment.html
  • Johnny Hughes at May 6, 2011 at 10:51 am

    On 05/06/2011 05:41 AM, Thomas Bendler wrote:
    2011/5/6 R P Herrold <herrold at owlriver.com <mailto:herrold at 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).



    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110506/a84722ee/attachment.bin
  • Thomas Bendler at May 6, 2011 at 1:15 pm
    2011/5/6 Johnny Hughes [...]

    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110506/fb21e3c4/attachment.html
  • Les Mikesell at May 6, 2011 at 1:29 pm

    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".

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ned Slider at May 6, 2011 at 2:25 pm

    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.
  • Charlie Brady at May 6, 2011 at 4:43 pm

    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?
  • Johnny Hughes at May 6, 2011 at 5:58 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110506/1a05e7d4/attachment.bin
  • Charlie Brady at May 6, 2011 at 6:19 pm

    On Fri, 6 May 2011, Johnny Hughes wrote:

    Almost everyone one of them has some kind of script written for it. Do
    all of them care about dist tag. Of course not.
    So please don't assert otherwise.
  • Johnny Hughes at May 6, 2011 at 6:23 pm

    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-supercomputer-in-cloud.html

    Ranger:
    http://blogs.sun.com/jonathan/entry/lone_ranger





    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110506/82ecf828/attachment.bin
  • John R. Dennison at May 5, 2011 at 7:21 am
    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

    --
    Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are, by
    definition, not smart enough to debug it.

    -- Brian W. Kernighan
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110505/76513682/attachment.bin
  • Dag Wieers at May 5, 2011 at 7:34 am

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

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Karanbir Singh at May 5, 2011 at 7:22 am

    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
  • Dag Wieers at May 5, 2011 at 7:30 am

    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.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Jean-Marc Liger at May 5, 2011 at 8:02 am

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110505/f8c0ceb6/attachment.html
  • Karanbir Singh at May 5, 2011 at 8:27 am

    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
  • Jean-Marc Liger at May 5, 2011 at 8:49 am

    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
  • Karanbir Singh at May 5, 2011 at 8:57 am

    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
  • Jean-Marc Liger at May 5, 2011 at 9:52 am

    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 ?
  • Karanbir Singh at May 5, 2011 at 10:02 am

    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
  • Jean-Marc Liger at May 5, 2011 at 10:18 am

    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
  • Karanbir Singh at May 5, 2011 at 10:31 am

    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
  • Jean-Marc Liger at May 5, 2011 at 10:40 am

    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
  • Karanbir Singh at May 5, 2011 at 10:48 am

    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
  • Jean-Marc Liger at May 5, 2011 at 11:03 am

    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
  • Karanbir Singh at May 5, 2011 at 12:56 pm

    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
  • Ned Slider at May 5, 2011 at 11:17 am

    On 05/05/11 15:48, Karanbir Singh wrote:

    as I said already, the disttag isnt used in the
    EVR compares for new package EVR> older package EVR
    Yes it is, see package ntp as per my earlier email.

    ntp-4.2.2p1-9.el5_4.1.src.rpm > ntp-4.2.2p1-9.el5_3.2.src.rpm
  • Jean-Marc Liger at May 5, 2011 at 8:35 am

    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110505/1d8d78bb/attachment.html
  • Ned Slider at May 5, 2011 at 11:15 am

    On 05/05/11 04:51, Johnny Hughes wrote:
    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?
    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.
  • Karanbir Singh at May 5, 2011 at 11:42 am

    On 05/05/2011 04:15 PM, Ned Slider wrote:
    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
    is that what really happened ?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedMay 4, '11 at 9:35a
activeMay 6, '11 at 6:23p
posts61
users12
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase