Gary Buhrmaster <gary.buhrmaster@xxxxxxxxx> writes: > On Thu, Nov 18, 2021 at 2:32 AM Josh Stone <jistone@xxxxxxxxxx> wrote: >> >> On 11/16/21 7:05 PM, Kevin Kofler via devel wrote: >> > Realistically, they will just stick to Fedora 36 forever and just stop >> > updating the devices (or try updating them anyway and get no updates from >> > the server, obviously). >> > >> > Sticking an EOL label on a software release is not going to magically make >> > it go away. >> >> Maybe so, but what can we do? >> >> We already did this for i686 hosts, and I'll bet there are still folks >> running F30 for that, or even EOL versions of currently supported >> arches. They may exist, but they "go away" from the perspective of what >> we choose to support. > > I have occasionally conjectured that there > should be a "last gasp" version of some > core package released into updates for a > version going unsupported that drops a file > into /etc/motd.d that is, essentially: > > "This version of Fedora is no longer supported" > > (and an equivalent banner for desktop login screen) > > That would not mean everyone would see > the message, nor would it stop people using > that version (I would think we do not want > to do so), but it might make it clear(er) to > some that there will be no further updates > in case the individual is not paying close > attention to the Fedora lifecycle. We've been toying with tooling specifically around this in the context of Amazon Linux as (unsurprisingly) we also have people using older versions. We're actually thinking around support periods being different for some packages than others, and being able to programatically communicate this and also alert users. While a motd update is nice, connecting into security and vulnerability scanning tooling is where this really works. The "what packages are supported for how long" part is already up at https://github.com/amazonlinux/dnf-plugin-support-info , and the check-release-update dnf plugin is shipping in AL2022 but we haven't put a nice github repo up yet (let me go and follow up on that now). Probably worth a different discussion and proposal though - something I've been meaning to find the time to write up :) The dynamic motd updates can be done pretty flexibly with pam-motd, with users easily opting out of anything in particular. The way we've been doing it is with a long existing (but not in fedora) package with a simple script called `update-motd`. We've primarily used it to do the nag on what security (and non-security updates) are available for the launched instance. Happy to get a public git repo of the source rather than just SRPMS for this too. Funnily enough though, the simple check of what updates are available can have a decent impact on instance launch time if you're not really careful about where and when that runs. _______________________________________________ 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
