(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? -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
