[Packaging] Repackaged DisplayCAL as Dummy Package

[Erich Eickmeyer]

Hi Robie,

On Sunday, June 20, 2021 10:36:02 AM PDT Robie Basak wrote:
> Hi Erich,
> 
> On Sat, Jun 19, 2021 at 03:32:18PM -0700, Erich Eickmeyer wrote:
> > While I would have created a snap version, I don't have the know-how, and
> > the flatpak version works very well. As such, we'd like to include this
> > flatpak version in Ubuntu Studio. I have packaged and uploaded a
> > "Transitional Dummy Package" of DisplayCAL which installs the flatpak and
> > adds the flathub.org flatpak repository if necessary. Please know that
> > this does NOT install any .deb repositories, and, therefore, does not
> > violate policy.
> 
> Thank you for writing up details of your plans and rationale. I can't
> express how much I appreciate proper communication and discussion of
> unusual things to ensure that everyone understands what is going on.
> 
> Presumably you're referring to
> https://lists.ubuntu.com/archives/technical-board/2018-February/002355.html
> and similar when you refer to not adding any .deb repositories.
> 
> > The justification for this is that the chromium-browser package currently
> > installs the snap of chromium. This is no different, except that it adds a
> > the flathub repository (the defacto-default repository for flatpak) if
> > necessary whereas only one snap repository exists (by design).
> 
> There are some differences. Somewhat overlapping in scope, but on the
> snaps-in-Ubuntu topic we have:
> 
> https://wiki.ubuntu.com/UbuntuSeededSnaps, to try and provide the same
> kind of provenance and stability type assurances for snaps that Ubuntu
> users get from Ubuntu releases, in the case that snaps are installed in
> an image by default.
> 
> The Snap Store as a source of software enabled by default comes with the
> Ubuntu project wide decision to trust that store by default. The same
> doesn't currently exist for Flathub.
> 
> The Chromium snap is published by Canonical. Perhaps this should have
> been done more formally, but ultimately it's currently the same team who
> were publishing Chromium as a deb in Ubuntu previously. On the other
> hand, it sounds like the DisplayCAL Flatpak is being published by a
> third party that operates completely outside Ubuntu's governance (CoC,
> etc).
> 
> Chromium already had the exceptional case as a deb that users would
> expect deviance from the usual Ubuntu stable release in that they'd get
> major behaviour breaking updates without notice (ie. a rolling release),
> so a transition to a snap didn't change this. Presumably, the same
> doesn't apply to the DisplayCAL Flatpak, and users would be switching
> from stability during the lifetime of a stable Ubuntu release to a
> rolling release type model for DisplayCAL?
> 
> These are some differences that come to mind right now. There may be
> others that occur to me later.
> 
> I hope that we can find a way forward, but it seems to me that we need
> to find some structure and define a more general policy here. That could
> be anything from delegating such decisions to individual flavours, to
> some general policy requirements to apply universally to make sure that
> user expectations are met.
> 
> I'd like to thank you again for bringing this up. I think this is worth
> figuring out!

Roping-in the Technical Board (which I know has some overlap with the release 
team) since there's some clear discussion that needs to happen at this level.

Technical Board: For reference, here's my original post: https://
lists.ubuntu.com/archives/ubuntu-release/2021-June/005235.html

I'm happy to contribute as much as I can to this and answer whatever questions 
may arise. We've been without DisplayCAL for a whole LTS release, and it's 
quite missed. I hope this doesn't happen again, and it would be nice to grab 
it in some form for 22.04 LTS.

I was very disappointed in the upstream author's inaction on this, and more 
recently disappointed in the upstream author of ArgyllCMS for exacerbating the 
problem by causing issues within Debian, as noted in my earlier post. Based on 
the two issues, it's an application that's very unlikely to have a .deb 
package ever again since we've basically descended into a dependency-hell-like 
situation where the only answer would be a snap or flatpak.

It's also a shame that the upstream author doesn't have much interest in going 
beyond Python2.7 and is primarily focused on Windows and macOS. I've made 
strides to create a snap version based on what was available in 19.10 where we 
last had a release of this package, but I can't seem to wrap my head around 
it. 

Either way, I believe you are correct, Robie, in that we need to come up with 
some sort of policy with regards to these situations. I feel a precedent has 
been set by Chromium in this regard, but yes, the flatpak for DisplayCAL is 
outside of Ubuntu governance. This would definitely put DisplayCAL into a more 
rollling-release.

Again, agreeing with you Robie, but I'm putting my Community Council Member 
hat on with this statement: just because Canonical does something, that 
doesn't automatically make it Ubuntu policy, nor does it automatically put it 
under Ubuntu's governance, and I'm sure everybody reading this email 
understands that. That said, unless I'm mistaken, the snap store isn't under 
Ubuntu's governance, but rather Canonical's governance. In this regard, it's 
no different than Flathub with the exception that Canonical is associated with 
Ubuntu (and owns the project, yet doesn't govern it). This is something to 
keep in mind when coming up with some sort of policy in this regard. In my 
opinion, if snaps are given an exception just because it's a Canonical 
project, then we need to allow community-based exceptions regarding flatpaks as 
well. That's just my 2c, but this needs to be better defined, and that's where 
the Technical Board comes in under that delegation.

Anyhow, I'm not arguing with anything, I'm just bringing up additional food 
for thought, and perhaps thinking out-loud, so to speak. Thanks for the 
information, and I look forward to whatever decisions are made. Rope me in on 
anything and everything in this regard. :)

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20210620/e0203659/attachment.sig>