 |
this concerns both rocky linux 8 and rocky linux 9 the correction must absolutely be made on these 2 distributions even Alma Linux and the other RHEL forks do not define these macros |
 |
>you have to delete the lines I'm not sure why you believe we have to. These are defined on purpose. We define %centos as there are packages that rely on this macro and we (like RHEL) rely on CentOS Stream in some capacity. Having this macro defined helps us ensure that rhel-specific things are disabled in some instances, reducing the need to patch packages more than necessary. Removing %centos is a non-starter as it may cause cascading issues down the road as we continue to build packages for Rocky Linux. >even almalinux and other forks of rhel do not define centos in their macros Are you sure AlmaLinux does not define these? Looking at these links, I can see them defined: https://git.almalinux.org/rpms/almalinux-release/src/branch/a8/almalinux-release.spec#L148 and https://git.almalinux.org/rpms/almalinux-release/src/branch/a9/almalinux-release.spec#L175 >this macro and especially use to detect the difference between rhel and it's fork and centos stream >so by defining it's 2 macros tell you that it's rocky is a fork not rhel but of centos stream Defining those two macros does not mean we're a fork of CentOS Stream. Yes, we build from CentOS Stream to prepare for the next point release. This has been standard behavior for this project since 2022. >the correction must absolutely be made on these 2 distributions It would be helpful to know why you believe those macros existing is causing problems. We have not seen or received reports of them being an issue. You have provided a snippet for what I assume is a package you are attempting to build, but nothing further beyond that. So assuming that is the case, you are relying on %{?rhel} to require epel-release, which in my opinion is fine. But you are then relying on %{?centos} to ask for epel-next-release, which is not fine regardless if it's Rocky Linux or another derivative that defines this. Rocky Linux (and other derivatives) purposely define %centos, because at the end of the day, we (including RHEL) rely on CentOS Stream. If you absolutely want to make sure *only* CentOS Stream gets epel-next-release, you may want to rely on %dist_vendor or %dist_name, which would be "CentOS" and "CentOS Stream" respectively. Setting to needinfo. |
|
|
except that on centos the macros %dist_vendor and %dist_name are non-existent this one is empty the only way to detect is to use centos or centos_ver it is variable were precisely created specifically for centos and no operating system that centos should use them |
|
|
>except that on centos the macros %dist_vendor and %dist_name are non-existent this one is empty the only way to detect is to use centos or centos_ver >it is variable were precisely created specifically for centos and no operating system that centos should use them This may be the case on CentOS 7 and Stream 8 (which are going end of life in May and June). On 9 and 10, this is not the case. You may want to ask yourself if it's really worth wanting to cover for two soon-to-be end-of-life releases. If you insist on covering for those, perhaps come up with another workaround that doesn't rely on that macro. There's plenty of ways to do what you want to do without trying to force us to make a potentially build system breaking change. %define osstring %(source /etc/os-release; echo ${NAME}) %if "%{osstring}" == "CentOS Stream" This is how it appears to me: * You are trying to force us to make a change solely for your own package * You are ignoring the reason why we have it defined and the implication of removing it (please see my earlier comment) * You are trying to cover for all CentOS releases despite the end of life coming up for 7 and Stream 8. Your argument seems to come down to the fact that we are not CentOS and nothing else. This is not me saying that this is false. This is me saying that you are ignoring points 2 and 3 above and you are not providing any other sufficient evidence that this is a widespread issue. |
|
|
Yes except that when I asked centos how to detect the difference between rhel and centos it was they who told me that I had to use either the centos macros or centos_ver that no other distribution than centos use it's macros and that if another distribution used them this one was in violation in short, I'm going to settle for the code that you gave and which seems to work so this story and to be settled between you rocky and centos |
- Anonymous
