On Sun, Jul 10, 2022 at 06:34:16PM +0200, Miroslav Suchý wrote: > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a): > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, > > > which have their own somewhat different release/life cycles? What about > > > module lifecycles? What is it about*lifecycles* that's important, > > > anyway? Don't we maybe want to just have a sort of generic system for > > > "important events"? > > I view it as a mechanism to communicate well in advance of when someone > > is going to have to do work. > > > > Fedora is the simple case: every 6-12 months you're going to have to > > upgrade the version of the OS. > > And when implementing this for Fedora, can you bear RHEL in mind too? Because it has several levels of EOL > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel RHEL is indeed more complicated. But RHEL already has its own subscription manager that knows when and to what extent a given installation has support. The two main ways to support SUPPORT_END= on such systems: 1. let the subscription management system fill out a date in os-release, based on the information it has. If appropriate, the date can be adjusted over time. 2. leave SUPPORT_END= unset, so that the existing mechanisms are used. Option 1. has the advantage that over time generic tools might learn to look at SUPPORT_END=. But if SUPPORT_END= is not a good fit for some reason, existing mechanisms can continue to be used, i.e. option 2. Which way is better will depend on the installation type and other details. I don't think we should try encode multiple levels of support in os-release. That file by design is simple: simple to write and simple to read and simple to interpret. More complicated state can stay external and be a source for the simplified information in os-release. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
