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