> I don't know. Sorry I don't have time to go into this right now. But the
> current situation seems worse, given that an automatic transition to an
> "external" snap, without prompting, goes against the principle that the
> TB already has consensus on.
>
> But, consider that this scenario won't be any different from any other
> package disappearing in a new release due to being unmaintained. Doesn't
> ubuntu-release-upgrader already do something sensible in this case?
>
> If someone would like to try and make the experience better than that,
> then please do! A debconf prompt with an explicit opt-in transition to
> the external snap was my other suggestion, for example, but that would
> require someone to prepare and test that upload.
For my part, end-user GUI applications have significantly different
characteristics than libraries and server components which are commonly
deployed in automated ways. GUI apps are more likely to need to
interoperate with other users using newer versions. In the most extreme
cases, a 'ten year stable release' would be actively harmful - as we
know from the security story on old browsers :)
For the cases where the application can be completely sandboxed without
content interfaces we can be confident that there are no integrations
which will break through change, and I think a careful snap-based
strategy has significant advantages.
If we wanted to, we could use series-named branches as the default
channel, giving us or the upstream maintainer some ability to keep
'focal' versions distinct from 'jammy' versions, for example. But in the
general case, I think these users would like to be on the current stable
version regardless of the underlying OS. I would like the latest
Telegram regardless of whether I am running IOS 15 or 16 on my iPad, and
similarly, the same latest version of Telegram regardless of whether I
am running Focal or Jammy.
I do think the release-upgrader is a reasonable place to handle such
deb-to-snap transitions, as it can provide a consistent UX for a range
of apps, rather than requiring individual deb-specific handlers. I also
think debconf prompts lean to the expert side of the equation, and the
sorts of apps that likely fit the profile for this sort of transition
lean to the consumer side of things.
Hope that helps,
Mark
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
