[Packaging] Repackaged DisplayCAL as Dummy Package

[Steve Langasek]

Apologies for missing the TB meeting this week.  I am broadly in agreement
with Robie's initial mail on this, but did have a couple of other comments
about nuances that I wanted to tease out.

First, on Canonical vs. Ubuntu: one thing we have been consistent about in
the past when enabling additional repositories by default in flavors has
been maintaining Canonical as a single root of trust.  This was true when
Ubuntu Kylin asked for an additional default repository for software only
licensed for distribution within China, and it is the case for the snap
store.  Flathub would fall far outside of this, as a repository maintained
by a third party that neither Ubuntu nor Canonical would have oversight
over.

Second, while the snap store is not under Ubuntu governance, we do at least
have draft guidelines (never officially ratified by the TB to date, but at
least a work in progress) that we expect seeded snaps to adhere to (or at
least, be on a path towards).  It is difficult to see how the displaycal
flatpak as it has been described would ever meet an equivalent set of
standards for flathub.

Third, regarding the flatpak enablement being done via a separate package,
that doesn't help if this is intended to be preinstalled as part of a live
image - which is the impression I had of what was meant by "including" this
in UbuntuStudio.  If that's the intention, then the process would need to
comply with all policies around third-party archives and their configuration
on behalf of users.


Also, this is entirely appropriate as a question to put before the TB; but
it may take some time to reach a conclusion, and I see not insignificant
risk that the outcome would not let you ship the existing flatpak by default
in UbuntuStudio.  So I would advise that, tactically, it may indeed be
faster and more straightforward if you were to work out how to provide this
as a snap under governance of the UbuntuStudio community.


On Wed, Jul 14, 2021 at 08:43:06AM -0700, Erich Eickmeyer wrote:
> Hi Robie,

> On Wednesday, July 14, 2021 5:46:40 AM PDT Robie Basak wrote:
> > Hi Erich,
> > 
> > We discussed this at the Technical Board meeting yesterday. We don't
> > have a full answer yet, but the general thought is that there are a set
> > of expectations for: 1) third party repositories enabled by default; and
> > 2) packages installed from third party repositories via the archive;
> > that we'd require to be met for arrangements of this kind. We think we
> > need to enumerate these specifically, and we're working on creating a
> > clear and unambiguous list for you.
> > 
> > Robie
> 
> This is good to hear. After reading through yesterday's TB meeting (I was deep 
> in my dayjob at the time and, while I saw the ping, it was too late), I'm 
> wondering if, perhaps, the flatpak-enabling bits need to be a separate package 
> that would make it explicit enough that the user knows they're enabling 
> flathub. That would be rather trivial to accomplish, and I'd be more than happy 
> to work on that.
> 
> Additionally, there's also the concern that this wouldn't even seed without 
> some sort of mechanism in germinate. Or, perhaps, I really need to take the 
> time to learn how to actually make a snap and turn this flatpak into a snap. I 
> know the opposite has been done, so maybe that needs to be done. I don't know, 
> I guess I'm just thinking-in-type here.
> 
> Either way, the application in particular is highly missed so we'd like to 
> have it back, one way or another. As I said before, a .deb package is nearly 
> impossible at this time as it has descended into dependency hell.
> 
> Thanks,
> Erich
> -- 
> Erich Eickmeyer
> Project Leader - Ubuntu Studio
> Member - Ubuntu Community Council

Regards,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20210716/09427e6b/attachment.sig>