[Packaging] Repackaged DisplayCAL as Dummy Package

[Christopher James Halse Rogers]

(Losing some context because I was apparently not subscribed)

> > 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).

My understanding was that the chromium-browser dummy-package was to
migrate people who currently have the chromium-browser package
installed to the snap, so the desktop team could stop maintaining the
actual chromium-browser deb.

Since the displaycal package doesn't appear to exist in any Ubuntu
release that Launchpad tracks, I don't think we need to migrate any
existing users of displaycal?

On the other hand, if you want to install displaycal by default in the
Ubuntu Studio flavour, then I'm not sure that seeding a package that
adds the flathub remote and installs the flatpak in preinst is going to
work to do that. I'm not entirely familiar with Ubiquity, but my
understanding is that does a file-copy from the live instance + some
post-processing rather than actually going through a dpkg install
process. That means the preinst wouldn't be run on the installing
system, but is instead presumably run during germinate on one of the
livecd builders. I would not expect the livecd builders to have access
to flathub (or any host outside of the LP build infrastructure).

For default-installed snaps we appear to have an explicit seeding
process, and snapd has a concept of seeded snaps. Perhaps what should
be done is to make an equivalent process for seeding flatpaks?