Hi Lonnie,
first, would you mind joining the discussion at the issue tracker so we have a single place where all information is gathered?
Source code repositories, package management and application dependencies are a huge challenge in the current age of end-users and developers alike.
I agree. So let us take one step at a time. The topic discussed in issue #1082 is about the mechanism to incorporate 3rd-party upstream source code with Genode's source code. I'm afraid naming the topic "package management" was a bit misleading, sorry.
Let us leave the "packaging" of Genode software ("package" as in container file for distribution) for later.
I have seen many efforts in these areas, and there does not seem to be a "best" solution that works for everyone.
On the developer side, I am a proponent for hierarchical tree structures in which you keep the main system components distinctively separated from things like 3rd part applications and the like.
Yes. This is exactly the motivation behind my suggestion (insertion of a "repos/" subdirectory) in the discussion in issue tracker.
I'm sure that this is not the best structure and layout, but the idea is that it keeps the Genode and the particular kernel completely separated from 3rd party apps and ports. This way you always know what the "system" needs for it basic minimal build a opposed to intermixing the drivers, libs, and applications like in other OS distributions.
...
Also, one thing that I really find bothersome in other OS distributions is that they tend to add all of the various system files together into a mess of files.
What I mean is that, for example, linux and windows will put application libraries mixed in with system libraries, and the like. This really makes a mess in the filesystem which promotes things like zombie libraries and configuration files, etc.....
I think we need to clearly distinguish the layout of a file system of an installed Genode-based OS and the layout of the source tree. Both layouts must satisfy different requirements.
I agree with your latter statement when referring to the layout of an installed OS. But within the source tree, there is no clear distinction between library code, application code, driver code, etc. For example, the FUSE-based file systems can be used as libc plugin (a library) or a service (a separate program). In many cases, components use intermediate libraries as a way to separate platform-specific parts from the main application (looking at the dynamic linker or the timer). Consequently there is no useful source-tree structure that separates libraries from components.
Genode's structure based on so-called repositories fosters the separation of lower-level from higher-level code. E.g., 'os' depends on 'base' but not vice versa. So when working on a topic, the developer has to make the conscious decision at which level his software resides.
Keeping our genuine source code separated from imported 3rd-party code is definitely desired. This is currently not the case. So we should improve the current state.
Perhaps one idea, might be to think about the way that "portable" applications are packaged in that they typically keep almost all of their needed libraries with the application that uses them. This could be good from the standpoint of different application versions needing different versions of the same libraries because they would be stored with the application and not the OS.
Also, the OS would not continue to grow to an unmanageable size due to application installations. This would allow for tighter control of the OS and its needed libraries, drivers, etc....
Just my opinion though and I am sure that there may be even better solutions than I have mentioned here, but currently, I advocate the Gentoo Portage (emerge) and Portable Applications approach as a possible solution.
All what you say resonates well with me. However, at this point, I'd prefer to focus the discussion on the source-code management.
Thank you for sharing your ideas! See you at the discussion thread at GitHub? ;-)
Cheers Norman