On Mon, 2 Mar 2020 15:52:58 -0300 Vinícius dos Santos Oliveira <[email protected]> said:
> Em seg., 2 de mar. de 2020 às 13:35, Carsten Haitzler <[email protected]> > escreveu: > > > you're going to find an afl runtime flatpak is going to have a lot of > > system > > lib deps... you will have to solve systemd support too :) > > > > Thanks for the answer. > > now e will have some problems for you too. acpid needs to be run by root on > > the host... you might find you have to ship lots of xlibs and wayland libs > > in > > the efl runtime... > > > > It's not a good idea to package any shell (be it a terminal shell like ZSH > or a graphical shell like E) to run on a sandbox. It doesn't make sense as > the shell will no longer let you explore your system but a sandboxed system > (so it doesn't perform a shell's job). SELinux or alike policies work > better on such programs. sure. you just will have to ensure e has no sandboxing at all. efl will have lots of deps and it's going to be a challenge to have a flatpak runtime that works on systemd vs non-systemd systems. e really mostly just needs efl plus libc/libm//liblibpthread the usual and libpam. if you build e with wl support it will also use libuuid from util-linux, libwqayland* libs and libxkbcommon too. as i said - at runtime e will want acpid running as root on most pc-like systems (not on things like rpi arm systems though will want it on bigger arm systems that are pc-like with acpi/uefi etc.). ppc systems also will likely want acpd running. also eeze in efl (that e uses) will probably want udisks running (possibly not in future as i have, in git, a new mounting replacement for e) an optional dep for e now also is libddcutil (provided by the ddcutil project) - runtime detected via dlopen. it'll have to be in /etc/ld.so.conf search paths and not LD_LIBRARY_PATH because it's used by a setuid root util for monitor backlight controls. it'll do more in future too like control color correction on the monitor and read monitor rotation sensors etc. it's actually essentially all there other than the whitelist of ddc cmds only allows backlight swizzling right now. i can whiteliest more over time as support in e's ui turns up. e has it's sysactions.conf file also customized per distro - it's an integration point to limit access to privileged features based on user and group membership. the power bits (shutdown/reboot/suspend ec.) are unused on systemd/logind systems as e will talk to it via dbus for these, but other things like the mounting, l2ping, rfkill etc. are necessary and may need customizing as the user/group membership may need. there is a new system.conf too in the same dir for the new setuid super-tool replacement. e will need rfkill installed for bt/bluez support to work right (and that's another system daemon/service needed - via dbus, but rfkill is needed to get some bt systems to work as they start rfkilled and asking bluez to power them on doesnt unblock the rfkill). e will need connman running for network control/support (also like bluez - running as root). there's pulseaudio for audio support as well. e can talk to alsa directly too though i never test that... that's what i can think of as a quick guide to dependencies and gotchas... > I only intend to create the runtime for apps based on EFL. But it's a good > idea to check what other libraries besides EFL E depends on. Maybe I should > put them as part of runtime if it looks like lots of apps will need them or > there is some reason for them to be updated behind the app's back (like > openssl and any crypto lib). > > > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
