Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible > notification when a Fedora stops being supported. Various proposals > for online checks were discussed in the bug, but I think we might make > do with something much simpler. We've been thinking a lot in this space in Amazon Linux, and have done some things that are starting to be a bit wider in scope in the AL2022 time frame, and that we've wanted to bring back as ideas to Fedora. One of which is simply how you tell someone there's something new they could move to. If doing so by the command line, you need to somehow work out what X to pass to `dnf system-upgrade ... --releasever=X`, while I'd much rather be able to put it in, say, the motd, and have other tooling be able to know through the same system that "why yes, you are up to date on patches on version X, but version Y is available" The GNOME Software Center parses the hard coded URL of https://admin.fedoraproject.org/pkgdb/api/collections/ which does already have an EOL tag on older Fedora releases, so this could be used today to print warnings all over the place if the format was standard enough and documented... and that other distros could use it easily enough with a custom URL without patching gnome-software... I would be totally in favor of some simple standard metadata we could host somewhere, easily configure into various bits of software that would prominently display it to users (or report back to some central thing, like various agents do with "dnf checkupdate" and "rpm -qa" output, that point to support statements about the OS. We actually have a skeleton design for such a thing (it says what updates and upgrades are available), but we've lagged on both posting to devel@ that it's something we've been working on, and I need to go and poke the person who needs to click the "publish this repo to github" button for the DNF plugin. I'll go do that now, as it would certainly add to this conversation. > https://github.com/systemd/systemd/pull/23924 proposes adding > SUPPORT_END=YYYY-MM-DD to /usr/lib/os-release. My idea would that we'd > e.g. pop up a desktop notification when that date is close, and a > bigger redder notification once it has been passed. The date could be > set to some initial value even on the initial release, and then > adjusted through updates to fedora-release.rpm if our schedule slips. > I guess we could add a notification during boot in systemd itself, but > most users wouldn't see that, so a graphical notification would also > be needed. This could already be done in Fedora with the data from the above URL, but something more generic could be nice, as well as finer grained, as a top level EoL date may not have the full picture. For Amazon Linux, we're wanting finer grained information as well, down to a per-package level, as that gives us the ability to do two things: 1. Clearly communicate an extended support period for a subset of the OS 2. Better ship and communicate life cycle multiple options of major versions of some packages (like MariaDB, PHP, PostgreSQL, Python) with their own support periods following upstream. We've done this by coming up with a "support_info.xml" kind of metadata, to be seen as somewhat related to "updateinfo.xml" except that it contains positive affirmations of support, as well as negative ones. This way, it can be used by external security scanning tooling to work out if there is any path to a particular installed RPM for ever getting another security update. Our first foray into this was with documenting the extension of EoL of Amazon Linux 1: https://github.com/amazonlinux/al1-support-statements and we've used the "explicitly no longer supported" mechanism internally. Our idea has been to use `system-release` (or some other yet to be defined thing) to communicate general OS-wide statements, althoug the nuance is important, and can be interpreted to be exactly what applies to the host you're running on. Arguably you want the warning of "hey, you have PHP7.4 installed, and it's EoL in November" just as much as you want "this whole OS is going out of support in X months". While this per-package level is less relevant for Fedora, it could be a useful mechanism to communicate things that are going to be deprecated in a future release. e.g. we could warn people that at some point the gtk1 they have installed is no longer going to be in Fedora, and where to go to for more information. I'm going to have to apologise for not all of ^ being written up sooner to devel@ as something we've been working on. But we did at least get the source code up for an initial DNF plugin that can parse it and give some tools to users to work out what is (and is not) supported: https://github.com/amazonlinux/dnf-plugin-support-info Our plan is to plug both of these into our update-motd package, which is simply something that writes out motd snippets for pam_motd based on running some scripts (such as 'dnf check-update') > The advantage of this proposal that it is very simple and will work > even on machines that don't have network connectivity, and can be easily > integrated into various DEs and tools. Agree that not relying on network connectivity is good. We've currently erred on the side of shipping our support_info.xml metadata just in the RPM of the DNF plugin, although that was mostly out of not wanting to go adding things to yum repo metadata without a good solid public discussion first rather than the great design choice of being independent of network connectivity :) _______________________________________________ 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
