Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
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).
Reply to: