On 30.07.17 13:47, Simon McVittie wrote: > On Sun, 30 Jul 2017 at 19:34:42 +0900, Benda Xu wrote: >> As far as I can see, the easiest relocations are those modifiable in a >> plain text, like configuration file, script shebang, etc. The medium >> ones are ELF, with which we have tools like patchelf and chrpath, etc. >> The most difficult part includes quite a few hidden path assumptions >> that can only be specified at build time, like the default GCC include >> dir. I don't know whether distributing binary packages can alleviate >> the barrier. Chances are many patches are needed to be carried to be >> able to override paths at run time. > Lots of packages hard-code paths at build time. This is often not > considered to be a bug. > > Flatpak's approach to this is to use bind-mounts (in a new mount > namespace set up by bubblewrap) so that the "app" (the leaf package, > together with any libraries that are bundled with it) always appears > to be installed in --prefix=/app, which can safely be hard-coded into > binaries that are built as Flatpak apps. > > Flatpak apps are normally recompiled from source with --prefix=/app, > but I don't think it's coincidental that /app is the same length as > /usr and can therefore be patched in with a binary editor as a last > resort :-) >
Users will not care if it is flatpak, singularity, conda or prefix - they want all the packages and the packages shall work. What I like about all of these efforts is that from what I grasped we will stop caring too much about backports. Also, what is today a bit clumsy to use because of all the dependencies, may become easier: snapshot.debian.org, once it decides to also monitor flatpaks, I mean. What it somewhat boils down to me is that we need to decide about the roles a Linux distribution shall have. And if we want problem-centric communities (like BioConda) to come up with a pan-distributional gentoo-prefix-like setup. The folks that are only after the immediate scientific findings will go for the community-effort. Those aiming for more, and here I see all the effort that goes into * package description + translation * man pages * hardened builds * reproducible builds * continuous integration tests (ok, BioConda does those too, now) * redundancy removal between packages I see our distribution's infrastructure as still relevant and also as an important momentum to drive the developments on upstream's side. To me, Singularity solves quite a bit as of today. But to win the contributors to BioConda of today, we would need to change a lot. Most drastically is the need for immediately relevant user feedback. The conda/brew folks solve that by github forks of their build instructions, which every user can immediately use. Debian falls behind on that front. And even when Debian decides to eventually surface more with its package build instructions, we would not have anything in place for users that want the binary update _now_ and not after an upload plus a likely manual review. So, for embracing our users more, we need to * allow them to install packages as users, not only as admins, which is what this thread is mainly about * allow them to seamlessly give feedback from which they can immediately benefit, which I do not see how to address without an autogenerated launchpad. Need to think about it all, many thanks for all your constructive feedback Steffen
