On Thu, Apr 11, 2019 at 7:01 PM Simon McVittie wrote: > The "app" (directly-user-facing part) in a Flatpak package will be mounted > on /app and so is expected to be built with --prefix=/app, so you can't > reuse a compiled binary .deb unless it's for something that happens to be > relocatable already. The runtime (chroot-like library stack to run apps) > is built with --prefix=/usr, so it's usually easy to reuse binary .debs > for that.
Has anyone done any rebuild testing to see how many packages hard-code the prefix in their binaries? Having to recompile everything once more for each "app" package seems like a lot of extra CPU time. Is there any reason that making /app a symlink to /usr (or a directory containing only links to /usr) wouldn't work inside Flatpak packages? I had planned to do this using mmdebstrap, which now offers installation of Debian systems that don't have apt/dpkg/essential, by using the new dpkg root stuff. I was blocked by the lack of a DPKG_CONFIG variable though, otherwise the system dpkg config interferes with the process if you have certain packages installed. > https://gitlab.collabora.com/smcv/flatdeb builds Flatpak runtimes from > an apt repository using debos and debootstrap. Hmm, last time you presented flatdeb, it wasn't using debos, how does debos get used in flatdeb now? > The example runtime recipes provided with > flatdeb are "Base" ... and "Games" I still think one runtime per "app" package is the way to go. It might also be interesting to start importing the standard Debian installations into an OSTree archive, so we could do things like bisect bugs between stable and current sid. As well as share files between all the runtimes and apps. -- bye, pabs https://wiki.debian.org/PaulWise