Re: User-installable Debian packages?
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
Reply to: