On Mon, Mar 19, 2018 at 02:36:05PM +0100, Julian Andres Klode wrote: > I think it might be useful to snap e2fsprogs, so we have a solution > for all older releases. Not to replace the package, but as a backport > that does not conflict with the system binaries.
A snap wouldn't be a bad thing, but I think there would be more to it than "just" publishing a snap in order to maintain parity against an SRU: 0. A user hitting the issue probably wouldn't have the snap installed, so would see e2fsck fail instead of it Just Working via an SRU. 1. While the snap would make a workaround available, I'm concerned that there would be no discoverability. How would a user, upon hitting a problem with e2fsck on Xenial fscking a Bionic system, find out about the snap solution? 2. What about maintenance? Right now, the Ubuntu security team is committed to maintaining e2fsprogs in the "deb archive" for security in Xenial, and Ubuntu as a whole for bugfixes, and an SRU wouldn't change that. A prudent sysadmin would want to avoid losing this support. So what kind of support commitment would come with that snap, and is anyone proposing to commit to the additional maintenance of this extra thing?
signature.asc
Description: PGP signature
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam