On Wed, Jul 13, 2022 at 6:29 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. I'm not aware of any plans to do that. > 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. Right. > 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. I agree. And RHEL's lifecycle(s) are fairly complex, depending on exactly what you want to know and what your usage scenarios are. I don't think SUPPORT_END fits there very well. josh _______________________________________________ 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
