Hi Ben! Could you please chime in to bug #901134 (RFS: anbox-modules)? This package wants to ship redundant copies of two modules (ashmem and binder) that are already in mainline since a long time ago. This strikes me as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I can't offer good advice.
On Wed, Jun 13, 2018 at 10:37:42AM +0800, Shengjing Zhu wrote: > On Wed, Jun 13, 2018 at 02:30:18AM +0200, Adam Borowski wrote: > > > anbox-modules-dkms - Android kernel driver (binder, ashmem) in DKMS > > > format > > > > Could you please explain (here and/or in the package's description) reasons > > why an user would prefer this version of the modules over what's in mainline > > kernel trees? > > > > This upstream repo in out-of-tree format can be built against various > kernel versions. > > I think upstream creates this repo because many distributions(including > most Debian based) don't enable these modules in their kernel. > > Since this repo already exists, then packaging it is more convenient to > enable these modules in kernel(and waiting other Debian derivatives to > sync up, not sure if they just sync with Debian or have own kernel > config). Indeed, these two modules are not built within Debian kernels. They depend on CONFIG_ANDROID, which doesn't look like it does anything anymore except allowing to enable these two modules. I have bad memories of Android kernels doing some very naughty things (magic hard-coded uids/gids, etc), but I don't know if that was related to CONFIG_ANDROID or not. Even if it was in the past, it seems that in mainline that setting is safe to enable. But, all of this lies in Ben's kingdom, of which I'm not knowledgeable enough. Thus, some advice would be nice. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).