Hi,
We plan to change the versioning scheme of the selinux-policy packages.
Based on a request to using tags in selinux-policy github repo, we discussed further actions and possible automation and decided to couple the tags with the package version, together with making a change for better comprehensibility.
So far, the package version changed with branching a new Fedora release off rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme was used for updates (3.14.7-1). After the change, the version would contain the Fedora branch number and the sequential number of the package in the branch (34.1), and the release part would be used only for changes in packaging (34.1-1). It would apply to Fedora 34 and newer.
In github repo, tags matching the Fedora package version would be used (v34.1), pairing the latest commit in github with the latest commit in the package (34.1-1).
We do not expect any impact to end users neither to developers unless the exact version was used somewhere. If there are no objections, we will make the change in a week time.
Cheers,
I'm still a little bit confused about the SELinux targeted policy "development" process versus the actual "roll-out," implementation, and deployment not only to Fedora on the deskop, but to various distributions of "CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in the cloud" especially on OpenVZ or other shared-kernel virtualization technologies as the case may be for businesses and end users who might otherwise benefit from SELinux Mandatory Access Control policies built in to the Linux kernel.
On Monday, March 29, 2021 11:56:23 AM AKDT Zdenek Pytela wrote:
Hi,
We plan to change the versioning scheme of the selinux-policy packages.
Based on a request to using tags in selinux-policy github repo, we discussed further actions and possible automation and decided to couple the tags with the package version, together with making a change for better comprehensibility.
So far, the package version changed with branching a new Fedora release off rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme was used for updates (3.14.7-1). After the change, the version would contain the Fedora branch number and the sequential number of the package in the branch (34.1), and the release part would be used only for changes in packaging (34.1-1). It would apply to Fedora 34 and newer.
In github repo, tags matching the Fedora package version would be used (v34.1), pairing the latest commit in github with the latest commit in the package (34.1-1).
We do not expect any impact to end users neither to developers unless the exact version was used somewhere. If there are no objections, we will make the change in a week time.
Cheers,
On Mon, Mar 29, 2021 at 10:45 PM justina colmena ~biz justina@colmena.biz wrote:
I'm still a little bit confused about the SELinux targeted policy "development" process versus the actual "roll-out," implementation, and deployment not only to Fedora on the deskop, but to various distributions of "CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in the cloud" especially on OpenVZ or other shared-kernel virtualization technologies as the case may be for businesses and end users who might otherwise benefit from SELinux Mandatory Access Control policies built in to the Linux kernel.
Most of the development happens in the rawhide github branch and selected commits subsequently go to stable Fedora releases as well as to Centos Stream and RHEL. There is no package difference between various Fedora editions and spins for the same version.
On Monday, March 29, 2021 11:56:23 AM AKDT Zdenek Pytela wrote:
Hi,
We plan to change the versioning scheme of the selinux-policy packages.
Based on a request to using tags in selinux-policy github repo, we discussed further actions and possible automation and decided to couple
the
tags with the package version, together with making a change for better comprehensibility.
So far, the package version changed with branching a new Fedora release
off
rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme was used for updates (3.14.7-1). After the change, the version would contain the Fedora branch number and the sequential number of the package in the branch (34.1), and the release part would be used only for changes in packaging (34.1-1). It would apply to Fedora 34 and newer.
In github repo, tags matching the Fedora package version would be used (v34.1), pairing the latest commit in github with the latest commit in
the
package (34.1-1).
We do not expect any impact to end users neither to developers unless the exact version was used somewhere. If there are no objections, we will
make
the change in a week time.
Cheers,
On Mon, Mar 29, 2021 at 1:56 PM Zdenek Pytela zpytela@redhat.com wrote:
We do not expect any impact to end users neither to developers unless the exact version was used somewhere. If there are no objections, we will make the change in a week time.
Final freeze begins a week from today. Even though the change is intended to be transparent, I wonder if it's better to make sure the change happens before freeze rather than appearing in an update after release with a different versioning scheme on released media (ISOs and images, etc).
I mention it now because for whatever reason some things that were stable already in the hours before beta freeze actually didn't make it onto beta composes.
On Wed, Mar 31, 2021 at 4:14 AM Chris Murphy lists@colorremedies.com wrote:
On Mon, Mar 29, 2021 at 1:56 PM Zdenek Pytela zpytela@redhat.com wrote:
We do not expect any impact to end users neither to developers unless
the exact version was used somewhere. If there are no objections, we will make the change in a week time.
Final freeze begins a week from today. Even though the change is intended to be transparent, I wonder if it's better to make sure the change happens before freeze rather than appearing in an update after release with a different versioning scheme on released media (ISOs and images, etc).
I mention it now because for whatever reason some things that were stable already in the hours before beta freeze actually didn't make it onto beta composes.
The freeze is on Tuesday, the plan is Monday, or after GA if it fails for some reason.
-- Chris Murphy _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
selinux@lists.fedoraproject.org
-
Chris Murphy -
justina colmena ~biz -
Zdenek Pytela