So, for the past week I've been trying to hide from some real life stuff and forget about this 30°C summer heat. What better way to do it, if not writing software nobody will care about? So far, it is still very early in development, but I've tried really hard to not use more hacks than I need to. There's plenty of time this time. For reference in this post, I will refer to it as the DBP system. This is not in any way final, and for any PND-system successor, it'd be mandatory to have at least 10 polls about its name. I just want something to call it when comparing it to the PND-system, k? The currently implemented features are not final, and they are not the final list of features that will be implemented. All dependencies so far exist in Debian Jessie, and I intend to keep it that way. Design goals * As few hacks as possible. No Zenity. Doing a system()-call instead of just properly implementing it in code is forbidden. * Correct the meta-data situation with PND's (raw append, wtf?) * Keep it extendable * Allow for terminal integration with DBP-installed programs * Potential for multi-user support Probably more stuff I can't remember DBP-files DBP-files consists of an optional SquashFS file, and an appended ZIP-file with meta-data. The core meta-data consists of at least one .desktop-file. All .desktop-files in a DBP are exported if they contain a "Desktop Entry" section. DBP-files themselfs have some core package data inside the "Package Entry" section inside "meta/default.desktop". These .desktop-files are exported mostly unchanged, with the only exception being that the Icon path is changed to an absolute path into the icon cache. Apart from desktop-files, executables are also exported, via a shellscript template, that invokes run-dbp with the arguments preserved. This template will also set up enviroment variables, if needed. The idea is that executables can be exported without having their enviroment mangled to redirect writes to appdata. As a result of executables being exported separatly, it means that if the .desktop-files themself only refer to executables already present on the system, and no other data needs to be included, it's possible to create a working package without a SquashFS image. This is unlikely to become a norm though, as the idea itself is a bit silly. It's merely a side-effect. DBP-system The DBP-system consists of two main parts. * A daemon running as root, that does package crawling and mounting. * A user program (dbp-run) that runs a program using package ID and executable path within the DBP as argument The daemon is configured via one configuration file, that sets stuff like icon/exec/image/union/appadata directories. It also depends on a shellscript template being available, that is used for emitting the executables. The daemon and user program communicates over dbus's system bus, so for this reason, dbus needs an additional config-file. Currently implemented features * Executable exports * .desktop and icon installation * Automatic crawling on media mount/umount * Very, very rudimentary executable launcing (requests to mount the aufs, does a system()-call, requests a umount.) ** Supports multiple instances of a program running without trying to umount when one quits * Directory watch for removed/added/modified DBPs * Proper application launching * Proper error logging (like pndrun_*.out) when launching DBPs. ** Needs to split stderr/stdout so that terminal stuff still works properly. Features I want to implement Soon™ * Modifying the exec shellscript to set up the enviroment, if needed * Automatic mimetype association for packages * Other stuff I've forgotten Features I'd like to see * run-dbp spitting out error messages with full gettext translation support * Some form of dependency tracking * Allow for some packages to show on the desktop * Multi-user support (with stuff like per-user appdata) * Maybe perhaps possibly sometime PND backwards compatibility * Other stuff I've forgotten Contributing Preferably, this thread should focus on this specific implementation, rather than the general direction a PND-replacement should go in. For general talk about a PND-replacement, there's already a thread about it. Code is currently hosted on github: http://github.com/slaeshjag/dbp The issue tracker there is probably the best place to file serious feature requests at. Anyone wanting to help is welcome to do so, and may ask on IRC what current issues are the most relevant.