© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
This looks like a carefully and correctly put together SRU.
However, it seems like an awful lot of change (eg. refactoring of how the maintainer scripts handle AppArmor) for very little gain in a stable release. Normally we try to avoid refactoring of this kind in an SRU altogether. From https:/
"In line with this, the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases."
Why is it necessary in this SRU to do this refactoring instead of just adding a single entry for /etc/ssl/
Even then, I am still doubtful about the usefulness of this SRU. It might be different if this were for Focal as it is the current LTS. But this is for Bionic only. I am generally assuming that new deployments will be made on Focal. The majority of Bionic users who would notice the warning have probably already noticed it. For the few who might want the warning to go away, they can already do that by tweaking the AppArmor profile locally.
There is always a cost to an SRU - both in terms of regression risk, and the frustration/
Assuming the only thing being fixed here is a warning to users in Bionic if they look in the logs, I'm not convinced that the benefit outweighs the cost, so I'm rejecting this SRU from the queue. Further discussion welcome if you think otherwise.