I think there's some miscommunication so I've tried to write up what I believe to be the SRU team's position below. To make progress I haven't had this text endorsed by the SRU team, but this reflects what I think we've agreed between ourselves verbally.
# General Principles The responsible Ubuntu developer team (in this case I think kernel?) makes a commitment to support packages in main and restricted for the lifetime of a release *at release time*. This is always on a "best effort" basis because of course bugs are subjective. But we do not renege on that support promise just because something we packaged is "EOL upstream". That happens all the time, and we provide support at distribution level regardless. The point is that our users can rely solely on our supported liftime without tracking commitments from thousands of upstream, and we deliver this in stable releases by (on the whole) not changing it. Thus it is not appropriate to post hoc dislaim support by "moving" the package to multiverse. The team that committed to supporting it must continue to meet that commitment. Packages in "restricted" receive support with the caveat that the best effort support we can provide is reduced because we do not have sources or there are other licensing restrictions. That's the only difference. It might cause a bug to go unfixed because we are unable to make the necessary changes to the driver. But that's not the issue here, so the fact that it is in restricted is not relevant to this case. The page you linked to says "patching bugs or updates may not be possible". But in this case, that's not at issue. We can still build the package against both the release kernel and newer kernels. Even if we were unable to build against newer kernels, that isn't a reason to push a change that regresses users of the release kernel. Updates during the lifetime of a stable release *must never regress support* in some way that worked previously. Obviously this is subjective as well (see the xkcd "spacebar heater"), but I don't think that subjectivity applies to this case. Dropping hardware support for users already supported is not acceptable. The hardware enablement exception does not excuse any of the above requirements. HWE is only permitted on the condition that existing users are not regressed. For the kernel this is usually relatively straightforward because upstream have the same rule. But it applies equally to other packages in the Ubuntu archive. This includes DKMS packages but also packages that might exist that build depend on DKMS package and provide those modules pre-built. In recent discussion in this bug there is talk of un-regressing the DKMS package, but I'd also like to know if prebuilt modules are affected please. I don't see why there would be a problem with continuing to sign packages that bundled the release pocket driver to keep Secure Boot working. But if Canonical wishes to stop signing them anyway then I guess they're entitled to do that[1]. However, as far as I'm aware it's perfectly possible to not regress anything _but_ the existence of that signature, so affected users would have to disable Secure Boot but not rearrange what packages they have installed. In this case the unsigned module should still continue to be bundled in packages that users might be relying upon, just not signed. If this requires tooling adjustments to achieve, then I think it's reasonable to make that a condition of dropping your signature. I think the UX also needs review in this case: how can we minimise the pain of the user suddenly being unable to boot because Secure Boot is enabled but the now unsigned kernel module cannot load? If some users have hardware that will no longer be supported by a newer driver but you still wish to provide HWE for users who have newer hardware, then we need to figure out how to split users into two streams so that users in the former case are not regressed. If we cannot figure this out, then that particular hardware enablement needs to be deferred to a future Ubuntu release. If you wish to achieve the changes you want in some other way, then we can try to figure something out. But whatever method you choose it must meet the baseline expectation that no existing user is regressed if they just continue to run apt upgrades. Requiring them to follow manual steps is not acceptable. You need to figure it out. If that means that you cannot provide HWE, then you cannot provide HWE. If there is a genuine situation that requires us to make an exception to the above, then that might be fine. For example, if there's a known severe security issue in something we shipped in restricted, then we might decide to remove it, since not doing so would be worse for users than regressing them. But I don't think that's the case here. The desire to provide regular hardware enablement updates does not justify such a regression. [1] Although if you do that often, perhaps we should reconsider if we should even release with such signatures any more. # This specific case In response to your specific questions: a) The revert of the DKMS package sounds good. b) +1 c) -1. See explanation above. But also, what about: d) 470-server, as asked by Daniel in comment #37 e) Are there any packages which provide this driver pre-built that has been bumped so as to cause this regression or a similar regression? See my explanation above of why I think these need adddressing too, if they exist. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2155202 Title: Latest Update Breaks Systems Using Nvidia 470 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+bug/2155202/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
