On Wednesday, October 19, 2016 7:50:23 AM EDT Matthew Miller wrote: > In the medium-term future, we might want to provide some application > software to users as Flatpak bundles in addition to traditional RPM > form. This should be generally transparent to users but provide (at > least) two advantages. First, these applications can be sandboxed, and > only able to access resources they're specifically allowed to, > increasing security. And second, users may have easier options for > mixing and matching application versions that match their personal > needs. And as a project, as Flatpak gains traction as a cross-platform > solution, providing a whole bunch of Fedora packages in this way even > to users of other distros helps increase our impact and usefulness to > the world. > > The Flatpak design splits the runtime from the application in the > filesystem — apps are built expecting the runtime at /usr as normal, > but are installed into a tree at /app. I'm not proposing that we move > to having /app, but the idea of having a separate tree is pretty > fundamental. As it stands right now, if we want to build existing RPMs > as Flatpaks, we have to either do some very sketchy magic with > relocation, or else hack on the specfiles. > > So, the crazy idea: what if, for applications which would be useful as > a Flatpak, we allow /opt/fedora/apps/[appname-version] as an allowed > prefix? Then, the exact same RPMs could be used by someone who doesn't > care about Flatpaks _and_ to construct the Flatpak, with no > really-invasive changes. (Perhaps by making a link inside the Flatpak, > or simply by asking for an extension to Flatpak to support the > different application root.) > > > From the FHS 3.0: > > /opt is reserved for the installation of add-on application > software packages. > > ... but it doesn't actually define what "add-on application software > packages" are. Although we integrate it all together in Fedora, > arguably a lot of our software could qualify. > > From our current Packaging Guidelines: > > /opt and its related directories (/etc/opt and /var/opt) is > reserved for the use of vendors in the FHS. We have reserved the > fedora name with LANANA for our use. If a package installs files > into /opt it may only use directories in the /opt/fedora hierarchy. > Fedora attempts to organize this directory by allocating a > subdirectory of our /opt/fedora directory for specific subsystems. > If you think you need to use /opt/fedora please file an FPC ticket > to decide whether it's a valid use of /opt and what subdirectory > should be allocated for your use. > > .... so, it's not completely outside the realm of precedent. I know > it's very different from our existing "blend everything into /usr" > approach, but I think it might be worth doing for the increased > flexibility. What do you all think? One of the major issues I see with this approach is the use of outdated libraries and other outdated packages. I know that Flatpak is important to a large number of people, but that isn't enough to suggest creating a prefix for each individual application, unless applications packaged in this way were separate from other packages, at which point we'd essentially have a distro on a distro. The solution to the above, as people who are for Flatpak would say, is to just keep the packages that make up your Flatpak as up to date as possible. If that were the case, we would have duplicate packages in each prefix increasing the size of a Fedora installation on all systems not using btrfs or a similar filesystem with deduplication or a similar technology. The solution to packaging RPMs as Flatpaks should be obvious. Simply changing the prefix to a temporary directory and using the resulting file tree would be the way to go. -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxx> Project Lead, OpenBlox https://openblox.org/ _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
